ANTOLOGIA

INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA
CREATIVIDAD TECNOLGICA Y CALIDA EDUCATIVA, PILARES PARA LA EXCELENCIA HUMANA
INGENIERA EN SISTEMAS COMPUTACIONALES
PLANIFICACIN Y MODELADO UNIDADE 1, 2, 3, 4

1.- PROCESO DE LA INGENIERIA DE REQUERIMIENTOS 2.- PLANIFICACIN DEL SISTEMA 3.- ANLISIS DEL PROYECTO 4.- ANLISIS DE LOS REQUERIMIENTOS
ING. INS LEN FLREZ
Justino Emmanuel Ruiz Bautista
7 A
ndice Unidad 1 1 Procesos de la ingeniera de requerimientos. 1.1 1.2 1.3 1.4 Requerimientos de proceso 2 Requerimientos para los usuarios (actores involucrados). 8 Requerimientos para el anlisis y negociacin 10 Requerimientos para la gestin10
Unidad 2 2 Planificacin del sistema. 2.1 Planificacin del tiempo.11 2.2 Evaluacin del costo benfico.12 2.3 Estudio de viabilidad..13 2.4 Planificacin de la documentacin.14 2.5 Gestin de la configuracin del software..15 Unidad 3 3 Anlisis del proyecto 3.1 Anlisis de riesgos.16 3.2 Control de calidad..17 Unidad 4 4 Anlisis de requerimientos 4.1 Requerimientos funcionales y no funcionales.. 18 4.2 Casos de uso. 19 4.3 Diseo De Interfaz De Usuario.20
Planificacin y Modelado
Pgina 2
1 Procesos de la ingeniera de requerimientos.
1.1 Requerimientos de proceso. Requerimientos del sistema Los Sistemas de Informacin por computadora normalmente estn integrados por muchos componentes. En la mayor parte de los casos, es difcil para los analistas entender todos estos componentes an mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relacin al propsito del sistema sus entradas y salidas de los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una investigacin en forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar en forma independiente. Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de informacin. Se clasifican en dos tipos:
1. Informacin.
Flujo
de
Datos.
2. - Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de
Estrategia del Flujo de Datos
Cuando se siguen un flujo a travs de los procesos de negocio, que es el propsito del anlisis del flujo de datos, le indica a los analistas una gran cantidad de datos sobre como se esta llevando a cabo los objetivos de la compaa. Al
Planificacin y Modelado Pgina 3
manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.
El anlisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los hallazgos en los diagramas de flujo de datos.
Estrategia del Anlisis de Decisiones
La estrategia del anlisis de decisiones es un complemento del anlisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operacin y de las decisiones que deben realizarse para cumplir con los objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, las estrategia de anlisis de decisin con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la la opcin que toman un supervisor de departamento para aceptar o rechazar pedidos.
La decisin de rechazar pedidos generalmente ocurre con mas frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante.
Pgina 4
Etapas 1. -
en
la
Estrategia las
del
Anlisis y
del
Flujo en
de
Datos marcha.
Estudiar
operaciones
procesos
2. - Identificar cmo se procesan los datos al manejar transacciones y terminar las tareas. 3. - Seguir el flujo de datos:
* * * * Salida
Proceso Almacenamiento Recuperacin
4. - Aadir gradualmente detalles a los niveles inferiores. Etapas 1. 2. 3. en -Estudiar Desarrollar Probar la los un el Estrategia objetivos modelo modelo del con del y Anlisis decisiones proceso datos de de de Decisin necesarias. decisin. prueba.
4. - Identificar los requerimientos del proceso para los datos. 4. Requerimientos De Salida Niveles de diseo
El diseo de sistema se representa a travs de dos fases: el diseo lgico y el diseo fsico. Cuando los analistas formulan un diseo lgico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus caractersticas: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto.
Pgina 5
El diseo lgico de un sistema de informacin es como el plano de un ingeniero para armar un automvil: muestra las caractersticas principales(motor, transmisin y rea para los pasajeros)y como se relacionan unas con otras(donde se conectan entre s los componentes del sistema, o por ejemplo, Cuando separadas estn las puertas.
Los informes y la produccin del analista son los componentes de todo el mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje. El diseo lgico tambin especifica las formas de entrada y las descripciones de las pantallas de todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las transacciones y los datos del proveedor. Las especificaciones de los procedimientos describen mtodos para introducir los datos, corridas de informes copiados de archivos y deteccin de problemas. El diseo fsico, actividad que sigue el diseo lgico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseo indican a los programadores que debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos. Utilizacin de los Datos de Requerimientos:
El alcance del diseo de sistemas se gua por el marco de referencia para el nuevo sistema desarrollado durante el anlisis. Los datos de los requerimientos, recopilados durante la investigacin, conforman las actividades y componentes del sistema. Los analistas formulan un diseo lgico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseo.
El diseo lgico va de arriba hacia abajo, como lo hizo la determinacin de requerimientos. En primer lugar se identifican las caractersticas generales, como informes y entradas; en el diseo de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato especfico para establecer cuanto espacio dejar en la informacin, en la pantalla de despliegue visual o archivo. Participacin de los Usuarios:
Los gerentes y usuarios del sistema tambin poseen un papel importante en le diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada. La participacin del usuario proporciona al analista una retroalimentacin importante conforme avanza en el diseo; adems asegura a los usuarios tengan un conocimiento no tcnico de lo realizara o no el nuevo sistema. Esta visin general del diseo de sistemas subraya los aspectos de diseo que se vern mas adelante en el diseo de la salida de sistema. Prototipo de Sistemas:
Los requerimientos del sistema y las especificaciones de diseo se establecen con claridad y son muy bien entendidas, y los analistas tienen la experiencia para convertir los requerimientos en un sistema eficiente y que trabaje bien. Los prototipos de sistemas pueden desarrollarse para proporcionar la informacin necesaria y producir un sistema adecuado. Razones para Desarrollar Prototipos de Sistemas:
A pesar de los mejores esfuerzos de los analistas de sistemas, las necesidades de informacin no siempre se establecen correctamente. Esto puede ocurrir por dos razones:
Los usuarios pueden saber solo lo que necesitan mejorar el sistema en ciertas reas del negocio, o que deben modificar los procedimientos existentes; por otro lado, conocer que mejor informacin para administrar ciertas actividades. Mtodos para el Desarrollo de Prototipos:
Los sistemas de prototipo se pueden desarrollar utilizando lenguajes de programacin y mtodos convencionales. El procesamiento y los controles de entrada pueden faltar y la documentacin del sistema normalmente falta en su totalidad.
La clave esta en las pruebas de las ideas y en proporcionar suposiciones sobre los requerimientos, no tanto en la eficiencia del sistema o en exactitud o perfeccin. En algunos casos cuando el sistema se utiliza en forma muy frecuente en la formulacin de La forma en que s esta llevando a cabo el diseo de salida del sistema. Diseo de la Salida de Sistemas:
A menudo, para los usuarios la caracterstica ms importante de un sistema de informacin es la salida que produce. Si la salida no es de calidad, se pueden convencer de que todo el sistema es tan innecesario que eviten su utilizacin y, por lo tanto, posiblemente ocasionen errores y que el sistema falle.
Pgina 8
Diseo Lgico de la Salida:
l termina "salida" se aplica a cualquier informacin producida por un sistema, ya sea impresa, desplegada o verbal. Cuando los analistas disean la salida, seleccionan mtodos para representar la informacin y crean documentos, informes u otros formatos que contienen informacin producida por el sistema.
Los mtodos de salida varan a lo largo de los sistemas. Para algunos, como un informe de inventarios de la cantidad de mercanca, el sistema del computador, bajo el control del programa, nada mas consulta los datos que se tienen a mano en el almacenamiento, y los ensambla en una forma que sea presentable. Otra salida puede requerir procesamiento sustancial, antes de que este disponible para utilizarlo.
Los analistas deben decidir cuando imprimir, desplegar o presentar su salida en forma audible. La salida impresa puede utilizar papel en blanco o formas reimpresas, la salida visual puede utilizar una o mltiples pantallas para desplegar informacin.
Seleccin de los Mtodos de Salida
Los sistemas de informacin ya sean que se desarrollen sobre sistemas pequeos de escritorio o sobre grandes sistemas, utilizan 3 mtodos principales para la salida los cuales se clasifican en:

Impresin Pantalla
Despliegue y audio
Salida Impresa
Este tipo de salida es la que se encarga de producir grandes volmenes de informes impresos, sin embargo la decisin de utilizar salida impresa no debe ser automtica, debe haber alguna razn como la necesidad de enviar a un cliente o proveedor un documento por correo, tener un registro impreso de los datos o circular una cantidad de informacin a diferentes personas en forma simultnea. Un informe bien diseado puede reemplazar a otro elaborados pobremente, proporcionando detalles innecesarios la cual no ayuda nada. Las opciones de salida impresa ms comunes en las empresas son en papel, informe filmados, formas especiales y formas para enviar por correo. Objetivos de la Salida
Expresar la Informacin Relacionada con Actividades Pasadas, Estado Actual o Proyecciones para el Futuro. Sealar Eventos Importantes, Oportunidades, Problemas Advertencia. Iniciar una Accin Confirmar una Accin. El objetivo principal durante el diseo de salida de la computadora es la informacin que ser presentada a las personas, puede afirmarse que la salida de la computadora es para las personas, es por esto que no se aborda la forma en que los datos se mueven entre los procesos o entre los almacenamientos de datos. Tipos de salida
La Salida del Sistema Puede Ser:

un reporte un documento un mensaje de acuerdo con las circunstancias y los contenidos, la salida puede ser impresa o presentada en una pantalla, el contenido de la pantalla tiene su origen en las siguientes fuentes:
Recuperacin de un Dispositivo de Almacenamiento. Transmisin desde un Proceso o Actividad del Sistema. Directamente desde una Fuente de Entrada. 6. Conclusin La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales:
Software, que son Programas de computadora, con estructuras de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas.
Pgina 11
Personal, son los operadores o usuarios directos de las herramientas del Sistema.
Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software.
Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin del Programa.
Procedimientos, o pasos que definen el uso especfico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.
Pgina 12
1.2 Requerimientos de los usuarios (actores involucrados).
3. Requerimientos De Entrada Es el enlace que une al sistema de informacin con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son:

Objetivos del Diseo de Entrada. Captura de Datos para la Entrada. Objetivo del Diseo de Entrada.
Consiste en el desarrollo de especificaciones y procedimientos para la preparacin de datos, la realizacin de los procesos necesarios para poner los datos de transaccin en una forma utilizable para su procesamiento as como la entrada de los datos se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos por personas que los escriben directamente al sistema. Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasos necesarios, estos son:

Control de la Calidad de Entrada Evitar los Retrasos Evitar los errores en los datos Evitar los pasos adicionales Mantener la Sencillez del Proceso
Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseador debe controlar la cantidad de datos en la entrada: - Las Operaciones de preparacin y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparacin de ingreso de los datos tambin lo son.
- La fase de entrada puede ser un proceso lento que toma mucho mas tiempo que el que necesitan las computadoras para realizar sus tareas. Evitar los Retrasos:
Tambin conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al disear la entrada, una forma de evitarle es utilizar los documentos de retorno. Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre mas pequea sea esta menores sern las oportunidades para cometer errores. Es comn encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:

Algunas veces el volumen de transacciones y la cantidad de datos en preparacin es algo que no se puede controlar por ello el analista experimentado, evitara diseos para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea aadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un da.
Mantener la sencillez del Proceso:
El sistema mejor diseado se ajusta a las personas que lo utilizarn y al mismo tiempo proporcionarn mtodos para el control de los errores, la simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que no exista ninguna garanta para el xito al instalar un sistema complejo y que domine. Captura de Datos para la Entrada:
En una transaccin existen datos importantes y otros que no, el analista debe saber cuales utilizar y cuales en realidad deben formar la entrada. Existen dos tipos de datos:

datos variables datos de identificacin
Datos Variables:
Son aquellos que cambian para cada transaccin o toman de decisin.

Datos de Identificacin:
Estos son los que identifican en forma nica el artculo que esta siendo procesado.
1.3 Requerimientos para el anlisis y negociacin.
Gerencia de Proveedores de Bienes y Servicios: 1. 2. 3. 4. 5. Calificacin Anlisis Precio Mximo en de de proveedores la /Llave u la seleccin de de contratistas y y comparativo contratos de en bienes y Mano y servicios.
licitacin
recomendaciones. /administracin otros. proveedores. presupuestos.
Garantizado
delegada Asistencia Anlisis
Negociacin de Contrato: 1. 2. 3. 4. Metas Desarrollo Anlisis del de Seguros de contrato/ /Fianza contrato y tiempo Revisin de y reportes y las costo. clusulas garantas. ejecutivo.
5. Administracin de contrato durante la construccin.
1.4 Requerimientos para la gestin.
Pgina 16
5. Requerimientos de almacenamiento La memoria de la computadora (RAM) es un lugar provisional de almacenamiento para los archivos que usted usa. La mayora de la informacin guardada en la RAM se borra cuando se apaga la computadora. Por lo tanto, su computadora necesita formas permanentes de almacenamiento para guardar y recuperar programas de software y archivos de datos que desee usar a diario. Los dispositivos de almacenamiento (tambin denominados unidades) fueron desarrollados para satisfacer esta necesidad. Los siguientes constituyen los tipos ms comunes de almacenamiento: Unidades de:

dispositivos de
Disco duro Disquete Compresin ZIP CD DVD
Disco Duro
El disco duro es el sistema de almacenamiento ms importante de su computador y en el se guardan los archivos de los programas - como los sistemas operativo D.O.S. o Windows 95, las hojas de clculo (Excel, Qpro, Lotus) los procesadores de texto (Word, WordPerefct, Word Star, Word Pro), los juegos (Doom, Wolf, Mortal Kombat) - y los archivos de cartas y otros documentos que usted produce.
Un Disco Duro en Buen Estado
Existen varias cosas que usted puede realizar para prevenir que la computadora le devuelve mensajes de error molestos. A continuacin encontrar una lista de programas diferentes disponibles para asegurarse de que la unidad de disco duro se mantenga saludable y funcionando a plena capacidad. (Estn disponibles estos programas de ejemplo a travs de Windows 95. Usted puede comprar otros programas para realizar las mismas tareas; simplemente hay que hablar con un distribuidor local de software para la computadora.) Utilidad de Desfragmentacin de Disco
Al transcurrir el tiempo, es posible que los archivos se vuelvan fragmentados porque se almacenan en posiciones diferentes en el disco. Los archivos estarn completos cuando los abra, pero la computadora lleva ms tiempo al leer y escribir en el disco. Estn disponibles programas de desfragmentacin que corrigen esto. Para obtener acceso al programa de desfragmentacin de disco bajo Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en Utilidad de Desfragmentacin de Disco.
Compresin de Datos
Usted puede obtener espacio libre en la unidad de disco duro o en disquetes al comprimir los datos que estn almacenados en stos. En Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en DriveSpace. Deteccin de Daos
Si experimenta problemas con los archivos, tal vez quiera averiguar si existen daos en el disco. ScanDisk de Windows 95 verifica los archivos y las carpetas para encontrar errores de datos y tambin puede verificar la superficie fsica del disco. Para ejecutar ScanDisk, haga clic en Inicio . Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en ScanDisk. Adems, es posible que la unidad de disco duro puede estar 'infectada' con un virus, si ha transferido los archivos o datos de otra computadora. Existen varios programas de deteccin y limpieza de virus que estn disponibles para usted. Simplemente hay que pedirlos del distribuidor local de software para computadoras.
Respaldo
Si la unidad de disco duro se descompone o si los archivos se daan o se sobrescriben accidentalmente, es una buena idea contar con una copia de respaldo de los datos de la unidad de disco duro. Estn disponibles varios programas de respaldo de uso con cintas, disquetes y aun con los medios desmontables. A menudo, la computadora tendr una utilidad de respaldo ya instalada. Unidad de Disquete y CD
Puede obtener acceso a la unidad de CD y la unidad de disquetes desde el panel frontal de la computadora. La unidad de CD consiste en un dispositivo de 5,25 pulgadas con una ranura cubierta o con una bandeja deslizable, un botn de carga / expulsin y un indicador de actividad luminoso. La unidad de disquetes consiste
Pgina 19
en un dispositivo de 3,5 pulgadas con una ranura cubierta, un botn de expulsin y un indicador de actividad luminoso.
Escritura
Lectura
Nombre
Tipos Disco disquete, Jazz, y Floptical. rgido, Zip, Bernouilli
Por grabacin magntica de pistas Por censado mediante la Disco concntricas mediante una cabeza misma escribi cabeza actuando que magntico en (para lectura escritura) Por modelado de hoyos formando una Censado por rayo lser CD-ROM pista en espiral, por inyeccin de de la longitud de los (slo plstico en un molde metlico hoyos grabados y de la lectura) distancia que separa dos hoyos sucesivos Por efecto trmico de un rayo lser se Censado por rayo lser CD-R (Slo modifica la transparencia de porciones de la longitud de las lectura) de una pista en espiral, en una capa de porciones transparentes material orgnico y las no transparentes de la espiral grabada Por grabacin magntica auxiliada por Censado potencia de campos MO (lectura (produccin masiva de CDs) constituida por un electroimn.
forma inversa
DVD-ROM (slo lectura)
accin trmica de una rayo lser de magnticos en las pistas y escritura) por su efecto en un rayo lser
Pgina 20
Por efecto trmico de un rayo lser de Censado por rayo lser CD-RW E DVD-RAM, PD potencia se modifica el estado cristalino del estado cristalino del (para de un material material de las pistas lectura escritura) y
2 Planificacin del sistema.
Etapa uno Planificacin Pre-Construccin Una clara visin, enfoque y direccin es esencial en un proyecto exitoso. El primer paso es formar parte de su Equipo y entrevistarnos con su alta gerencia para hacer propios su filosofa, objetivos y metas corporativas; as como establecer que sus presupuestos y cronograma de trabajo se ajusten al plan de negocio. Estas reuniones son clave, ya que definen los parmetros bajo los cuales se medir el xito del proyecto. La planificacin de pre-construccin permite un anlisis lgico y ordenado sus necesidades fsicas y cul es la ptima configuracin y metodologa del trabajo requerido. Adicional al anlisis fsico para nuevas construcciones o remodelaciones, se realiza un profundo anlisis de la zonificacin, normas municipales, permisos necesarios, estructura impositiva, aspectos laborales, y otros costos blandos que puedan influir en el presupuesto, que son revisados minuciosamente.
Pgina 21
Etapa Dos: Diseo El 80% de los costos duros se definen en el primer 30% del la fase de diseo. Debido a que el potencial para lograr ahorros disminuye sustancialmente posterior a esta etapa, es importante contar con la experticia de su equipo CBB en las primeras etapas del proyecto. Ayudaramos a aclararle a los profesionales proyectistas tales como arquitectos, ingenieros, constructores y proveedores todas las especificaciones y requerimientos para lograr ptimos resultados. Sobre disear agrega costos y una especificacin pobre aumentar costos de operacin y obligar a efectuar gastos imprevistos en mejoras. Investigaremos, analizaremos, recomendaremos y haremos seguimiento a los profesionales y contratistas aprobados para asegurar el fiel cumplimiento a sus compromisos contractuales. Mantenemos actualizado una base de costos para asegurarnos que los presupuestos de proyecto se estarn cumpliendo. Elaboraremos proyecciones y estimaciones de costos de operacin y mantenimiento predictivo para las instalaciones en su posterior fase de operacin. Etapa Tres: Revisin de Presupuestos La coordinacin del proceso de diseo asegura que las especificaciones y planos de construccin estn completos, garantizando que los presupuestos incluirn todas las partidas esperadas. Planos inexactos, falta de detalles, e instrucciones deficientes a los contratistas licitantes resultarn en aumentos de obra sustanciales o posiblemente la sustitucin de materiales de baja calidad por los contratistas.
El equipo CBB prepara un paquete completo de licitacin con instrucciones

precisas, la metodologa de construccin y los cronogramas de tiempo esperados. Antes de proceder a invitar las empresas a licitar Usted estara totalmente informado de las diferentes maneras que existen de solicitar propuestas y cmo influyen en los objetivos del proyecto. Precio Mximo Garantizado, Suma Global Modificada, Llave en Mano, Administracin Delegada o Fast Track, entre otros, son mtodos de solicitud de propuesta que seran analizados para limitar y controlar los posibles ajustes de los costos de construccin.
Pgina 23
Etapa Cuatro: Negociacin Cuando se reciben las diferentes cotizaciones, el equipo CBB efecta comparaciones manzanas con manzanas tomando muy en cuenta los aspectos que cada contratista excluye de su cotizacin. Se preparan entrevistas con cada contratista para analizar partida por partida el contenido de su propuesta y solicitar las revisiones si as fuera necesario. El Equipo recomendara a usted el contratista que a su juicio es el ms apropiado para llevar a cabo la tarea, para posteriormente iniciar las negociaciones contractuales. CBB revisara y preparara contratos que por experiencia han sido exitosos en estos casos, reduciendo la carga de abogados externos quienes solo tendran que revisar y modificar documentos ya pre-elaborados. Los contratos incluyen proteccin contra daos, penalidades por incumplimientos, clusulas de incentivo y procedimientos de pago, cierre de obra y modificaciones.
Etapa Cinco: Monitoreo de la Construccin Con el equipo de gerencia CBB estructurado, se efectan las revisiones finales de seguros, fianzas, seguridad fsica y permisos en la obra. Durante el proceso se desarrollar una actividad continua e intensa de control de calidad, control de costos y control de avance cierto. Por medio de una constante presencia en la obra y reuniones de coordinacin peridicas estableceremos estrictas normas de reporte para todos los involucrados. Presentaremos reportes ejecutivos y detallados en diferentes formatos para su revisin y control. Etapa Seis:
Pgina 24
Cierre Un aspecto vital que es comnmente olvidado es el cierre del proyecto. Esta actividad asegura que las instalaciones quedan operativas, listas para abrir al pblico, de acuerdo a las metas corporativas previstas. El equipo CBB prueba todos los equipos y todos los sistemas haciendo entrega de las instalaciones al equipo que va a operar las instalaciones. CBB rene todas las garantas y manuales de operacin e instruye al personal en modos eficiente de operacin de sus nuevas instalaciones. Aseguramos que las revisiones y lista de chequeo se efecta en el momento apropiado para asegurar que usted recibe una instalacin funcionando y con la informacin tcnica necesaria para su futura operacin y mantenimiento. Llevamos a cabo una auditoria del proyecto como parte de nuestro programa de Calidad Total para conciliar costos y para efectuar las crticas de procedimientos que puedan mejorar futuras instalaciones similares. Sugeriremos un programa de mantenimiento, predictivo y preventivo para asegurar estabilidad en sus costos de operacin y mantener las instalaciones en un ptimo estado de funcionamiento de tal manera que el mantenimiento no interfiera con la actividad medular de su empresa.
Asistiremos en el proceso de mudanza en todas sus etapas; asegurando que la puesta en marcha de las oficinas se lleve a cabo sin mayores tropiezos o incomodidad. Esta es una etapa crtica que requiere de intensa supervisin para poder finalizar los proyectos con gran xito.
2.1 Planificacin del tiempo.
Pgina 25
La planificacin en tiempo real es uno de los campos de investigacin ms activos en la informtica. En este apartado, se ofrecer una introduccin a los distintos mtodos de planificacin en tiempo real y se estudiarn dos algoritmos de planificacin clsicos. En un estudio de los algoritmos de planificacin en tiempo real, se observa que los distintos mtodos de planificacin dependen de s el sistema lleva a cabo un anlisis de planificacin: en caso afirmativo, si se realiza esttica o dinmica: y si el resultado del anlisis genera un plan con respecto al cual se expiden las tareas durante la ejecucin. Basndose en estas consideraciones, los autores identifican las siguientes clases de algoritmos:
Mtodos con tablas estticas: realizan un anlisis esttico de las planificaciones de expedicin posibles. El resultado del anlisis es una planificacin que determina, un tiempo de ejecucin, cuando debe comenzar la ejecucin de una tarea.
Mtodos preferentes con prioridades estticas: tambin se realiza un anlisis esttico, pero no se realiza ninguna planificacin. En cambio, se usa dicho anlisis para asignar prioridades a tareas, de forma que se pueda emplear un planificador convencional preferente con prioridades.
Mtodos de planificacin dinmica: se determina la viabilidad en tiempo de ejecucin (dinmicamente) en vez de antes de empezar la ejecucin (estticamente). Se acepta una nueva tarea para ejecutar slo si es factible cumplir sus restricciones de tiempo. Uno de los resultados del anlisis de
Pgina 26
viabilidad es un plan o proyecto empleado para decidir cuando se expide cada tarea.
Mtodos dinmicos del mejor resultado: no se realiza ningn anlisis de viabilidad. El sistema intenta cumplir todos los plazos y abandona cualquier proceso ya iniciado y cuyo plazo no se haya cumplido. La planificacin con tablas estticas es aplicable a tareas peridicas. La entrada del anlisis consta del tiempo peridico de llegada, el tiempo de ejecucin, el plazo peridico de finalizacin y la prioridad relativa de cada tarea. El planificador intenta trazar un plan que le permite cumplir las exigencias de todas las tareas peridicas. Este es un plan que le permite cumplir las exigencias de todas las tareas peridicas. Este es un mtodo predecible, pero tambin es
inflexible, puesto que cualquier cambio en las exigencias de una tarea. Son tpicos de esta categora los algoritmos de planificacin de primero el plazo ms prximo u otras tcnicas peridicas de plazos. La planificacin preferente con preferente con prioridades estticas hace uso del mecanismo de planificacin referente con prioridades, habitual en la mayora de los sistemas mltiprogramados que no son en tiempo real. En un sistema que no es real, puede emplearse una gran variedad de factores para determinar la prioridad. Pro ejemplo, en un sistema en tiempo compartido, la prioridad de un proceso cambia dependiendo de s tiene carga de procesador o
de E/S. En un sistema en tiempo real, la asignacin de prioridades se encuentra relacionada con las restricciones de tiempo asociadas a cada tarea. Un ejemplo de ese mtodo es el algoritmo montono de frecuencia, que asigna prioridades estticas a las tareas en funcin de sus periodos.
La planificacin dinmica basada en un plan, despus de que una tarea llega al sistema, pero antes de comenzar a ejecutarla, se intenta crear un plan que contenga las tareas previamente planificadas, as como la recin llegada. Si la recin llegada puede planificarse de forma que se cumplan sus plazos y que no se pase ningn plazo de las tareas ya planificadas, se revisa el plan para hacer sitio a
la nueva tarea.
Pgina 28
La planificacin dinmica del mejor resultado, es el mtodo utilizado en la mayora de los sistemas en tiempo real comercializados en la actualidad. Cuando llega una tarea, el sistema le asigna una prioridad en funcin de sus caractersticas. Normalmente, se emplea alguna forma de planificacin por plazo, como puede ser la de primero el plazo ms prximo. En general, las tareas son peridicas, por lo que no es posible un anlisis esttico de planificacin. Con este tipo de planificacin, no se sabe si se va a cumplir una restriccin de tiempo hasta que vence el plazo o la tarea termina. Esa es la mayor desventaja de esta forma de planificacin. Su ventaja est en la facilidad de implementacin.
2.2 Evaluacin del costo beneficio.
Debern aplicar la metodologa para la evaluacin costo-beneficio de la regulacin todos los entes y rganos de la Administracin Pblica. Dicha metodologa, estarn obligados a completarla cuando se establecen nuevas
Pgina 29
regulaciones o se reforman las existentes que establezcan trmites, requisitos y procedimientos, sobre inscripciones, registros u autorizaciones.
La metodologa se compone de dos tipos de formularios con sus correspondientes guas de llenado. El Formulario de Evaluacin Costo-Beneficio (formulario uno) se debe completar para los casos en que las propuestas de regulacin establezcan nuevos trmites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones, o modifiquen o eliminen trmites existentes. En este ltimo caso, cuando se eliminen trmites, se deber completar este formulario slo si en adicin a tal eliminacin se modifican o se crean nuevos trmites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones. En caso contrario, deber proceder a llenar el Formulario Simplificado de Evaluacin Costo-Beneficio (formulario dos) debe completarse para el caso en que la propuesta de regulacin sea una reforma a un trmite existente, en la cual nicamente: se eliminan documentos y requisitos innecesarios, se establezcan plazos definidos, se reduzcan los plazos de resolucin, o se disminuyan los procedimientos. Para realizar este anlisis deber completarse el Formulario de Evaluacin CostoBeneficio (formulario 1) o el Formulario Simplificado de Evaluacin CostoBeneficio (formulario 2), segn sea el caso, siguiendo las guas de llenado correspondientes. Lo anterior, puede obtenerlo en las siguientes opciones:

Directriz Decreto Formularios Guas de llenado 2.3 Estudio de viabilidad.
Pgina 30
A. Concepto y Funciones Plan de empresa, memoria del proyecto empresarial, estudio de viabilidad o
"business plan",
no son ms que las diferentes formas de denominar o referirse al En l se sintetiza y refleja toda la concepcin del
documento escrito en el que se recoge toda la informacin relevante referida a una

empresa en proceso de creacin .
negocio, todas las informaciones y reflexiones realizadas por los emprendedores durante el proceso de estudio del proyecto empresarial. Puede ser considerado como un instrumento al servicio del emprendedor o grupo de emprendedores, un apoyo para la creacin de su empresa, puesto que su realizacin requiere un esfuerzo vlido por s mismo, al servir de gua de actuacin en las diferentes etapas a seguir en el proceso de creacin hasta la puesta en marcha de la actividad empresarial, permitiendo el conocimiento de las condiciones que intervendrn en el futuro. Es muy importante que en su elaboracin participen todos los socios o promotores, de forma que todos ellos se impliquen plenamente en los objetivos que se establezcan y en la manera de conseguirlos.
Decdete a actuar ... TU PUEDES SER UN LIDER cmo actan los lderes? cmo ganar carisma? As pues, el plan de empresa cumple tres funciones bsicas:
Pgina 31
1. Comprobar la coherencia interna del proyecto. 2. Permite cohesionar al grupo humano durante su elaboracin (se
prueba el compromiso de trabajo, de dedicacin al proyecto por parte de cada promotor).

3. Al
contener todos los datos relevantes, es la idnea para ir a buscar
tarjeta de clientes,
presentacin
recursos,
colaboradores, etc. Su estructura y orientacin depender de cul sea el objetivo de ese plan. Incluso dentro de un mismo tipo de plan de empresa, dependiendo del proyecto, se dar ms importancia a unos puntos que a otros. Tambin es conveniente precisar que el plan de empresa no debe considerarse como un esfuerzo puntual sino como una herramienta al servicio del emprendedor que se debe ir actualizando de manera constante y que, cuando sea preciso, nos permitir obtener una fotografa de cul es la situacin en un momento determinado. Hay que tener presente que incluso las grandes empresas (que quieren seguir creciendo y seguir siendo rentables) invierten cada mes muchos recursos en la elaboracin de informes o "cuadros de mando" en los que se detalla la evolucin de la empresa en los ltimos meses as como las previsiones de evolucin futura a corto, medio y largo plazo y que esos informes, que no son ms que un plan de empresa para cuando sta ya est creada, son considerados como una herramienta de ayuda imprescindible para la toma de decisiones por parte de los altos directivos.
2.4 Planificacin de la documentacin. DESCRIPCIN Y OBJETIVOS Mientras que el Plan de Sistemas de Informacin tiene como objetivo proporcionar un marco estratgico que sirva de referencia para los Sistemas de
Informacin de un mbito concreto de una organizacin, el objetivo del Estudio de Viabilidad del Sistema es el anlisis de un conjunto concreto de necesidades para proponer una solucin a corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. La solucin obtenida como resultado del estudio puede ser la definicin de uno o varios proyectos que afecten a uno o varios sistemas de informacin ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situacin actual. A partir del estado inicial, la situacin actual y los requisitos planteados, se estudian las alternativas de solucin. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisicin de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas, indicando los requisitos que cubre. Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organizacin, la inversin a realizar en cada caso y los riesgos asociados. Esta informacin se analiza con el fin de evaluar las distintas alternativas y seleccionar la ms adecuada, definiendo y estableciendo su planificacin. Si en la organizacin se ha realizado con anterioridad un Plan de Sistemas de Informacin que afecte al sistema objeto de este estudio, se dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el proceso. Las actividades que engloba este proceso se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realizacin resultados originados en actividades anteriores.
Pgina 33
2.5 Gestin de la configuracin del software. La gestin de la configuracin del software es uno de los procesos clave para toda organizacin dedicada a la Ingeniera del Software, ya que posibilita una mejor organizacin del desarrollo y mantenimiento, consiguiendo la visibilidad del producto y facilitando el resto de procesos de produccin. En este artculo se muestra cmo se ha elaborado un Plan de Gestin de Configuracin del Software para un proyecto de I+D en colaboracin entre Empresa y Universidad. Los iniciales planteamientos de realizacin de un control informal de cambios para evitar interferencias entre los nuevos componentes a desarrollar por parte del equipo de la Universidad y el mantenimiento del sistema de produccin realizado por la empresa fueron dando paso la definicin de un plan de GCS completo, tanto para el desarrollo del proyecto como para los desarrollos futuros realizados internamente en la empresa.
3.1 Anlisis de riesgos.
Qu es un anlisis de riesgos?
Las graves crisis alimentarias que han azotado Europa recientemente han suscitado un intenso debate acerca de la seguridad del suministro de alimentos. Tambin han dado lugar a la creacin de la Autoridad Europea de Seguridad Alimentaria (European Food Safety Authority, EFSA). La EFSA se har cargo de la evaluacin cientfica de riesgos, mientras que las decisiones en materia de gestin de riesgos son competencia de los legisladores y polticos de la Unin Europea.
Los riesgos son evaluados y gestionados en el marco del denominado anlisis de riesgos. Este artculo explica en qu consiste. Tenemos claro lo que queremos decir con el trmino riesgo? Una definicin sera la probabilidad del advenimiento de un acontecimiento adverso, problema o dao y las consecuencias del mismo. Evaluar riesgos y determinar la mejor manera de gestionarlos en la compleja y amplia escala de la Unin Europea constituye un gran desafo. Es difcil apreciar todos los aspectos de un riesgo y prever todas las consecuencias de una medida de control, ya que siempre habr cierto grado de incertidumbre. El anlisis de riesgos es una forma sistemtica de evaluar mejor los riesgos, lograr transparencia en su complejidad y resolver las dudas o lagunas. Este sistema facilita la adopcin de decisiones en materia de gestin de riesgos y su comunicacin. El anlisis de riesgos est compuesto de tres etapas: evaluacin de riesgos, gestin de riesgos y comunicacin de riesgos.
Evaluacin de riesgos En lo que respecta a la alimentacin, el riesgo implica un impacto potencial en los consumidores. Los microorganismos infecciosos, las sustancias qumicas contaminantes (por ejemplo, los productos de limpieza) o los agentes fsicos (como el cristal) entraan posibles peligros relacionados con los alimentos. A pesar de que se realizan todos los esfuerzos posibles para minimizar los peligros, la seguridad alimentaria no es absoluta y stos peligros siempre pueden darse. La evaluacin de riesgos aplica un enfoque estructurado para estimar el riesgo y comprender mejor los factores que intervienen de forma positiva o negativa. Un riesgo puede evaluarse en trminos absolutos (por ejemplo, calculando el nmero
de consumidores que enferman cada ao por comer determinados productos) o en trminos relativos (por ejemplo, comparando la seguridad de un producto con la de otro).
Gestin de riesgos Los gestores de riesgos dirigen el anlisis de riesgos, deciden si la evaluacin de un riesgo es necesaria o no para resolver un problema y apoyan a los evaluadores en su trabajo. Una vez realizada la evaluacin, los gestores de riesgos se basan en el resultado para decidir qu medidas hay que tomar. Cuando es preciso reducir el riesgo, la gestin de riesgos debe optar por las mejores medidas posibles para lograrlo.
Comunicacin de riesgos En el anlisis de riesgos, existen diferentes tipos de comunicacin importantes. Los aspectos tcnicos se debaten entre gestores, evaluadores y partes interesadas del sector privado. A la hora de decidir cul es la mejor manera de controlar un riesgo y de ejecutar las decisiones, la comunicacin entre los gestores de riesgos y los sectores pblico y privado es muy importante. Este debate es menos tcnico y tiene en cuenta, por ejemplo, puntos de vista ticos, sociales y econmicos. A fin de tomar una decisin que se adecue al objetivo y sea aceptable para todas las partes interesadas, la gestin de riesgos debe asegurar una comunicacin adecuada. Mucha gente opina que la comunicacin de riesgos no es ms que una actividad de relaciones pblicas, pero la verdad es que la
disciplina ha evolucionado de forma independiente, sobre todo gracias a las teoras de la percepcin de riesgos. La percepcin de riesgos hace referencia a una amplia serie de estudios psicolgicos, que se iniciaron hace unos cincuenta aos con objeto de analizar por qu unos riesgos se perciben de una forma y otros de otra. Esta investigacin mostr que a la gente le afectan ms los riesgos involuntarios que los voluntarios, y se preocupa ms por los problemas tecnolgicos que por las catstrofes naturales. Estos descubrimientos influyeron enormemente en la manera de presentar los riesgos ante la opinin pblica. Las estrategias iniciales de comunicacin de riesgos funcionaban de arriba abajo, por ejemplo, de un legislador al pblico. Actualmente, se prefiere una forma dialctica en la comunicacin de riesgos que anime al pblico y las partes interesadas a participar activamente en el proceso comunicativo.
3.2 Control de calidad.
Una de las reas de la actividad humana en la que la aplicacin de tcnicas estadsticas ha tenido gran difusin y al mismo tiempo un enorme xito, es en la de aquellos aspectos que se relacionan con el control de calidad de produccin de bienes y suministro de servicios. En los aos 80 la aplicacin de la filosofa y tcnicas del control de calidad en la produccin supuso un enfoque revolucionario y tremendamente competitivo, que fue aprovechado sobre todo por la industria japonesa para colocarse a la cabeza del mercado mundial, lo que resulta curioso,
siendo americanos los "padres" del control de calidad, puesto que la industria americana slo se subi al carro del control de calidad una vez que la presin ejercida en el mercado por la superioridad de los productos japoneses les oblig a considerar las bondades de la nueva filosofa, en la que la calidad constituye un concepto global que no slo se aplica al producto sino a todo el proceso de fabricacin, incluyendo el control de costes, precios y beneficios, gestin de los suministros y plazos de entrega. Aunque inicialmente el control de calidad se aplic solo a la fabricacin industrial, enseguida se extendi su radio de accin a la prestacin de servicios, donde tambin podemos incluir el rea de salud, aunque dentro del entorno mdico hay sectores que por sus caractersticas, ms asimilables a la industria, tienen una mayor tradicin en el empleo del control de calidad; como son los laboratorios de anlisis clnicos (hematologa, bioqumica o microbiologa), o los bancos de sangre. Sin embargo las tcnicas han sido utilizadas tambin en otros entornos, como puede ser por ejemplo en la monitorizacin de fallos en operaciones quirrgicas, y su campo de aplicacin est limitado tan slo por nuestra imaginacin, ya que cualquier actividad humana es susceptible de ser cuantificada y por tanto monitorizada para mejorar su calidad, desde el tiempo de espera de un paciente que acude a consulta, hasta el porcentaje de pacientes que cumplen adecuadamente el tratamiento prescrito, o el mismo registro de datos en la historia clnica del paciente. Un elemento fundamental en la filosofa del control de calidad moderno es la utilizacin generalizada de procedimientos cientficos, incluidos los mtodos estadsticos, en la planificacin, recogida de datos y anlisis de los mismos, de tal forma que las decisiones no se sustenten en meras conjeturas. Aunque en un sistema sanitario fundamentalmente pblico, como es el espaol, la competencia no constituye el principal acicate para la incorporacin de sistemas de control de calidad, no cabe ninguna duda de que sin embargo existen mltiples razones para incorporar estas tcnicas en la gestin de los servicios de atencin
sanitaria, como lo corrobora el hecho del aumento de su difusin y aplicacin en este entorno, razones en las que de momento no vamos a entrar, por ser la lnea argumental de estos artculos fundamentalmente estadstica.
En este documento vamos a echar un vistazo a lo que se conoce como Control estadstico de procesos, metodologa que utilizando fundamentalmente grficos permite monitorizar la estabilidad (calidad) de un proceso de produccin o de suministro de un servicio, de forma que se detecte, cuanto antes, cualquier situacin inadecuada; lo que permitir eliminar las causas especiales de variabilidad en la obtencin del resultado final.
4.1 Requerimientos funcionales y no funcionales.
Introduccin
En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los aos, la Ingeniera de Software ha introducido y popularizado una serie de estndares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en s. Se han publicado muchos libros y artculos relacionados con este tema, con el modelado de procesos del negocio y la reingeniera. Un nmero creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en da la economa global depende ms de sistemas automatizados que en
pocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva dcada de procesos y estndares de calidad. Sin embargo, cmo explicamos la alta incidencia de fallos en los proyectos de software? Por qu existen tantos proyectos de software vctimas de retrasos, presupuestos sobregirados y con problemas de calidad? Cmo podemos tener una produccin o una economa de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema? Tal vez suene ilgico pero, a pesar de los avances que ha dado la tecnologa, an existen procesos de produccin informales, parciales y en algunos casos no confiables. La Ingeniera de Requerimientos cumple un papel primordial en el proceso de produccin de software, ya que enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. La razn principal para escoger este tema se fundament en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro pas somos partcipes de este problema a diario, en donde se ha vuelto comn la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas. Tal "personalizacin", la mayora de las veces, termina retrasando el proyecto en meses, o incluso en aos. La problemtica del ao 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados. El reemplazo de plataformas y tecnologas obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas
que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definicin de los requerimientos. Estudios realizados muestran que ms del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participacin del usuario, requerimientos incompletos y el cambio a los requerimientos, tambin ocupan sitiales altos en los motivos de fracasos.
Con este trabajo se pretende alcanzar los siguientes objetivos:
Resaltar la importancia que tiene la Ingeniera de Requerimientos dentro del ciclo de desarrollo. Dar a conocer las diferentes alternativas que existen para identificar requerimientos.
Ayudar a comprender la diferencia que existe entre las diferentes tcnicas utilizadas en la IR.
Minimizar las dudas que se tiene sobre los casos de uso. Mostrar la utilizacin de herramientas CASE dentro de la administracin de requisitos. 2. La ingeniera de requerimientos y sus principales actividades
Qu son Requerimientos?
Pgina 41
Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE . (1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2). Los requerimientos puedes dividirse no en requerimientos funcionales. funcionales y
requerimientos
Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Caractersticas de los requerimientos
Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser remplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros.
Pgina 43
Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Ingeniera de Requerimientos vs. Administracin de Requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa.
A continuacin se darn algunas definiciones para ingeniera de requerimientos.
"Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del
Pgina 44
comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia son:
de
la
Ingeniera
de
Requerimientos
Los principales beneficios que se obtienen de la Ingeniera de Requerimientos
Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.
Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios.
Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.
Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.).
Pgina 45
Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso.
Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. Personal involucrado en la Ingeniera de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.
4.2 Casos de uso.
Casos de Uso (Use Case) Introduccin El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.
Elementos
Actor:
Una definicin previa, es que un Actor es un 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 ms bien la labor que realiza frente al sistema. Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
Caso de Uso:
Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.
Pgina 47
Relaciones:
o
Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.
Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.
Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica.
Pgina 48
De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda clsica de usar o heredar. Ejemplo: Como ejemplo esta el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el nmero de temes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total
El usuario/cliente presiona el botn de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos temes han sido retornados en el da. b. Al final de cada da el operador solicita un resumen de todo lo depositado en el da.
El operador debe adems poder cambiar: a. Informacin asociada a temes. b. Dar una alarma en el caso de que: i. ii. Item se atora. No hay ms papel.
Pgina 49
Como una primera aproximacin identificamos a los actores que interactan con el sistema:
4.3 Diseo De Interfaz De Usuario
El propsito de la interfaz es muy simple: recoger de los usuarios la informacin del sistema y ponerla a disposicin de otros usuarios. La informacin recogida se llama entrada del sistema y se almacena en la base de datos para ponerla a disposicin de los dems usuarios. La informacin suministrada se llama salida del sistema. Es decir, el diseo de interfaces cubre tanto las entradas como las salidas. Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz interactiva, el usuario se comunica directamente con el ordenador y la salida se obtiene muy poco tiempo despus de la entrada. En el caso de entradas o salidas no interactivas, es decir, por lotes, las transacciones se renen en formularios en el punto de recepcin y despus se introducen en el ordenador al mismo tiempo. Estas transacciones se procesan y un tiempo despus se producen las salidas, las cuales se pasan al usuario. As, el tiempo transcurrido desde la introduccin de los datos hasta que se obtiene una respuesta puede ser considerable. El diseo de interfaz interactivo provoca un dilogo hombre-mquina que permite un intercambio rpido de informacin entre los ordenadores y sus usuarios humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para contener la informacin en el que las entradas normalmente se realizan en formularios especialmente diseados y las salidas se producen en un listado impreso.
Pgina 50
Ser necesario definir los formatos individuales de las pantallas utilizadas. En el caso de utilizar un paquete estndar, habr que evaluar la posibilidad de adoptar el tipo de formato del producto. Entre los aspectos a considerar en los formatos de pantalla se destacan: encabezamiento, cuerpo principal, pie, teclas de funcin, teclas de ayuda y lneas de visualizacin de los mensajes de ayuda. Tambin hay que describir, de forma detallada, los dilogos entre pantallas y su encadenamiento. Para ello, es til representarlas jerrquicamente, de forma que en los niveles superiores se representen los mens, y en los niveles inferiores las pantallas de dilogos, representativas de funciones o procesos concretos del sistema. En esta representacin jerrquica nos interesa identificar los mens o dilogos concretos en funcin de los grupos de usuarios que los utilicen. Ser tambin necesario determinar los dilogos que se consideran crticos para un funcionamiento correcto del nuevo sistema. Los dilogos crticos se determinan en funcin de factores como: tipo de proyecto, grado de cambio con respecto al sistema actual, complejidad de los trabajos del sistema. Entre las consideraciones a tener cuenta a la hora de disear pantallas se encuentran las siguientes: Caractersticas deseadas: simplicidad, claridad y fcil de comprender. Ser necesario tener claridad visual, de forma que los elementos estn agrupados de forma comprensible y con significado en vez de al azar y de forma confusa. Saber dnde situar la informacin en la pantalla. Ser necesario indicar un punto de partida obvio en la esquina superior izquierda de la pantalla, reservar reas especficas de pantalla para diferentes tipos de informacin (como, por ejemplo, mandatos, mensajes de error, ttulos y campos de datos, de forma que esta consistencia se mantenga en todas las pantallas) y proporcionar una composicin que guste visualmente (es decir, que est balanceada, sea simtrica, sea predecible, secuencial, simple, con agrupamientos, etc.).
Saber qu informacin situar en la pantalla. Para ello, hay que poner slo la informacin que es esencial para la toma de una decisin o para la ejecucin de una accin (No inundar al usuario con informacin!) y poner todos los datos relacionados con una tarea en una nica pantalla (as el usuario no tiene que recordar datos de una pantalla a otra).
Saber cmo situar la informacin en la pantalla. As, en cuanto a las fuentes de letras, se recomienda utilizar minsculas para el texto con la letra inicial de la frase en maysculas; para las etiquetas, encabezamientos o subttulos utilizar maysculas. En cuanto a las palabras, se recomienda no usar jerga, sino utilizar palabras cortas, familiares, etc.
La interfaz de entrada debe recoger todos los datos necesarios, sin introducir errores, para el sistema. De esta forma, la interfaz contiene una proteccin contra errores de entrada. As mismo, tambin debe recoger los datos minimizando el nmero de teclas pulsadas por el usuario. Las entradas deben estar bien estructuradas y ser fciles de comprender y utilizar. Se deben usar nombres precisos y permitir abreviaturas cuando se necesiten introducciones rpidas de datos.
Se deben evitar las entradas repetitivas. Igualmente, el diseo de la salida asegura que se extraen todos los datos suministrados por el sistema y que esas salidas estn estructuradas de forma que sean fciles de leer.
El color aade una nueva dimensin a la facilidad de uso de la pantalla, ya que atrae la atencin del usuario. Si se utiliza de forma adecuada, puede
Pgina 52
resaltar la organizacin lgica de una pantalla, facilitar la separacin de componentes y acentuar las diferencias. Por el contrario, si se usa inadecuadamente, puede distraer y fatigar la visin debilitando la facilidad de uso del sistema. Por ejemplo, en las pantallas grficas se recomienda no utilizar ms de seis colores a la vez, evitar colores extremos (rojo y azul, amarillo y prpura), evitar colores que no tengan contraste (blanco y amarillo, rojos, azules).
4.3.1 Reglas En El Diseo De Interfaz De Usuario
PRINCIPIOS A SEGUIR EN EL DESARROLLO DE INTERFACES DE USUARIO: A) Dar control al usuario B) Reducir la carga de memoria del usuario C) Consistencia A) DAR CONTROL AL USUARIO Permitir a los usuarios utilizar teclado o ratn. Permitir al usuario interrumpir su tarea y continuarla ms tarde. Utilizar mensajes y textos descriptivos. Permitir deshacer las acciones, e informar de sus resultados. Permitir una cmoda navegacin dentro del producto y una fcil salida del mismo. Permitir distintos niveles de uso del producto para usuarios con distintos niveles de experiencia. Hacer transparente la interfaz del usuario (este debe creer que trabaja directamente con los objetos). Permitir al usuario personalizar la interfaz.
Pgina 53
Permitir al usuario manipular directamente los objetos de la interfaz. El usuario debe sentir que tiene el control del sistema.
B) REDUCIR LA CARGA DE MEMORIA DEL USUARIO Aliviar carga memoria corto plazo (deshacer, copiar y pegar, mantener los ltimos datos introducidos). Reconocimiento antes que recuerdo (elegir de listas mejor que teclear). Dar indicaciones visuales de donde est el usuario, que est haciendo y que puede hacer a continuacin Proporcionar funciones de deshacer, rehacer y acciones por defecto.. Proporcionar atajos de teclado (iniciales en mens, teclas rpidas). Asociar acciones a los objetos (men contextual). Utilizar metforas del mundo real (sistema telefnico, agenda). Presentar al usuario solo la informacin que necesita. Hacer la presentacin visual clara (colocacin/agrupacin de objetos, excesiva informacin). C) CONSISTENCIA Permite al usuario utilizar conocimiento adquirido en otros programas consistentes (P.e. Mostrar siempre el mismo mensaje ante un mismo tipo de situacin aunque se produzca en distintos lugares). Consistencia en la realizacin de tareas: proporcionar al usuario indicaciones sobre el proceso que est siguiendo. Consistencia dentro de un producto y de un producto a otro.
Presentacin Comportamiento Interaccin Ejemplo consistencia en la mejora de la interfaz: Botones de las ventanas de Windows (3.11 y 95/98).
Consistencia en los resultados de las acciones: misma respuesta ante misma accin. Consistencia en la apariencia esttica (iconos, fuentes, colores, distribucin de pantallas, ...) Fomentar la libre exploracin de la interfaz, sin miedo a consecuencias negativas.
4.3.2 Integracin De La Interfaz Al Caso De Uso Aunque se han propuesto modelos diferentes para el diseo de la interfaz de usuario (Por ejemplo, NOR86, NIE00), todos sugieren alguna combinacin de los siguientes pasos: 1. Con base en la informacin desarrollada durante el anlisis de la informacin, definir los objetos y las acciones de la interfaz (operaciones). 2. Definir eventos (acciones del usuario) que cambiarn el estado de la interfaz Modelar este comportamiento. 3. Representar cada estado de la interfaz tal como lo vera el usuario final. 4. Indicar como interpreta el usuario el estado del sistema a partir de la interfaz proporcionada mediante la interfaz. En algunos casos, el diseador de la interfaz puede empezar con borradores de cada estado de la interfaz (es decir, el aspecto de la interfaz en distintas circunstancias) y luego trabajar hacia atrs para definir objetos, acciones y otra informacin importante para el diseo. Independientemente de la secuencia de las tareas del diseo, ste debe: A) Seguir siempre las reglas de oro analizadas. B) Modelar la manera en que se implementar la interfaz
Pgina 55
C) Tomar en cuenta el entorno (por ejemplo, la tecnologa de despliegue, el sistema operativo, las herramientas de desarrollo) en que habr de usarse. APLICACIN DE LOS PASOS DEL DISEO DE LA INTERFAZ Un paso importante en el diseo de la interfaz es la definicin de los objetos que esta tendr y las acciones que se les aplicarn. Para realizarlo se analizan los casos de uso. Es decir, se escribe una descripcin de un caso de uso. Luego se aslan los nombres (objetos) y los verbos (acciones) para crear una lista de objetos y acciones. Una vez definidos los objetos y las acciones, que se han elaborado de manera iterativa, se organizan por tipo. Se identifican objetos de destino, origen y aplicacin. Un objeto origen (como el icono de un informe) se arrastra y coloca en un objeto de destino (por ejemplo, un icono de impresora). La implicacin de esta accin es crear un informe impreso. Un objeto de aplicacin representa datos especficos de la aplicacin que n ose manipulan directamente como parte de la interaccin con la pantalla. Por ejemplo, en una lista de correo se almacenan nombres para un envo de correspondencia. La propia lista podra ordenarse, combinarse o purgarse (acciones de men), pero no arrastrarse ni colocarse mediante interaccin del usuario. Una vez que el diseador queda satisfecho con un objeto importante y que se han definido las acciones (para una iteracin de diseo) se realiza el formato de la pantalla. Como otras actividades de diseo de la interfaz, el formato de la pantalla es un proceso interactivo; en el se elabora el diseo grfico y se colocan los iconos, la definicin de texto descriptivo en pantalla, la especificacin y la asignacin de nombres a las ventanas, adems de la definicin de los elementos primarios y secundarios de los mens. Si un metfora de la realidad es apropiada para la aplicacin, se especifica en este momento, y el diseo se organiza de manera tal que satisfaga la metfora. A continuacin se presenta un caso de estudio preliminar (escrito por el propietario) para la interfaz.
Pgina 56

ANTOLOGIA

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ANTOLOGIA

Hochgeladen von

Copyright:

Verfügbare Formate

INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA

CREATIVIDAD TECNOLGICA Y CALIDA EDUCATIVA, PILARES PARA LA EXCELENCIA HUMANA

INGENIERA EN SISTEMAS COMPUTACIONALES

PLANIFICACIN Y MODELADO UNIDADE 1, 2, 3, 4

ING. INS LEN FLREZ

Justino Emmanuel Ruiz Bautista

1 Procesos de la ingeniera de requerimientos.

2. - Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de

Estrategia del Flujo de Datos

Estrategia del Anlisis de Decisiones

Proceso Almacenamiento Recuperacin

Diseo Lgico de la Salida:

Seleccin de los Mtodos de Salida

La Salida del Sistema Puede Ser:

1.2 Requerimientos de los usuarios (actores involucrados).

Control de la Calidad de Entrada:

Evitar los Pasos Adicionales:

Mantener la sencillez del Proceso:

datos variables datos de identificacin

Son aquellos que cambian para cada transaccin o toman de decisin.

1.3 Requerimientos para el anlisis y negociacin.

recomendaciones. /administracin otros. proveedores. presupuestos.

delegada Asistencia Anlisis

5. Administracin de contrato durante la construccin.

1.4 Requerimientos para la gestin.

Disco duro Disquete Compresin ZIP CD DVD

Un Disco Duro en Buen Estado

Tipos Disco disquete, Jazz, y Floptical. rgido, Zip, Bernouilli

DVD-ROM (slo lectura)

2 Planificacin del sistema.

El equipo CBB prepara un paquete completo de licitacin con instrucciones

2.1 Planificacin del tiempo.

2.2 Evaluacin del costo beneficio.

Directriz Decreto Formularios Guas de llenado 2.3 Estudio de viabilidad.

documento escrito en el que se recoge toda la informacin relevante referida a una

prueba el compromiso de trabajo, de dedicacin al proyecto por parte de cada promotor).

contener todos los datos relevantes, es la idnea para ir a buscar

3.1 Anlisis de riesgos.

3.2 Control de calidad.

4.1 Requerimientos funcionales y no funcionales.

Con este trabajo se pretende alcanzar los siguientes objetivos:

Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas.

A continuacin se darn algunas definiciones para ingeniera de requerimientos.

Los principales beneficios que se obtienen de la Ingeniera de Requerimientos

4.2 Casos de uso.

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.

4.3 Diseo De Interfaz De Usuario

4.3.1 Reglas En El Diseo De Interfaz De Usuario

Das könnte Ihnen auch gefallen