Tarea 1 Conceptos Mgr. Indira Camacho del Castillo UMSS: Cochabamba - Bolivia

Tarea 1Conceptos

Mgr. Indira Camacho del CastilloUMSS: Cochabamba - Bolivia

Conceptos Ingeniería de sistemas:

Es un modo de enfoque interdisciplinario que permite estudiar y comprender a los sistemas, con el propósito de implementar u optimizar sistemas complejos.

Ingeniería de requerimientos:Enfoca un área fundamental: la definición de lo que se

desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema.

Ingeniería de producto:Es el software acabado, esta orientado a hacer sistemas para

mercados grandes, se concentra en las características que tiene que tener el producto para ser vendido, comercializado.

Ingeniería de procesos negocios:Se hace software para una empresa, se observa como trabaja

o funciona una empresa, modifica la estructura organizacional de una institución(tareas que ocupaban funcionarios ahora los procesa el software).

Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia

2Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software

Conceptos Ingeniería de software:

Es el proceso de desarrollo de software, mediante métodos y técnicas para resolver problemas reales de la sociedad.

Ingeniería de requisitos:Facilita el mecanismo apropiado, para comprender lo que

quiere el cliente. Es parte de la ingeniería de requerimientos. Ingeniería de pruebas:

Un producto no probado no sale al mercado, constantemente buscan errores e identifican, ellos van probando y se aseguran de que el producto sea de calidad.

Sistemas de información:Es un conjunto de partes que interactúan entre si para

lograr un objetivo.

El sistema de información es considerado como un conjunto de componentes interrelacionados que recuperan, procesan, almacenan y distribuyen información para soportar la toma de decisiones, la coordinación y el control de una organización.



RelacionesBajo el concepto de ingeniería de sistemas se entiende

una ciencia que estudia como mejorar los sistemas organizacionales, de producción, ventas, comercialización y otros. Para ello normalmente se apoya en sistemas computacionales

Cuando la ingeniería de software se orienta a una organización se denomina ingeniería de proceso de negocios.

Cuando se orienta a un producto se denomina ingeniería de producto.

Para que ingeniería de software nos ayude a construir sistemas complejos o simples debemos hacer uso de la ingeniería de requerimientos o requisitos, ingeniería de pruebas y otros procedimientos.



Relaciones Ing. Sistemas

Ing. producto

Ing. Software

Ing. Proceso

negocios

Sistemas de información automatizados

Ing. de requerimientos = Ing. de requisitos

Ing. de pruebas



Repaso Tarea 1:

Contrastar/relacionar/definir: Mejor si muestran mediante un diagrama las relaciones/diferencias entre los siguientes conceptos:

Ing. Sistemas Ing. Producto Ing. Software Ing. Requisitos

Ing. Requerimientos Ing. Proceso NegociosSistemas de información Ing. Pruebas



Actividades de: •Análisis•Planificación



Análisis de sistemas

ObjetivoProductoEl Documento de Especificación de

requerimientos sirve para realizar el contrato entre el cliente y el

desarrolladorExisten dos paradigmas a través de los cuales se

enfrenta la actividad análisis de sistemas: Paradigma Estructurado Paradigma Orientado a Objetos



Actividades del Análisis1. Estudio de Factibilidad2. Obtención y análisis de

requerimientosComprensión del dominio Prototipado (opcional)Recolección de requerimientosClasificación de informaciónResolución de conflictosPriorizaciónVerificación de requerimientos

3. Especificación de requerimientos

4. Validar requerimientos

1. Reconocimiento del problema

2. Evolución y síntesis: (Modelamiento /prototipeo)

3. Especificación4. Revisión Final



Repaso Tarea 1:

Análisis de Sistemas2.Identificar los paradigmas que se utilizan

para el análisis de sistemas. Explicar los 2 más usados y por cada uno de ellos señalar las herramientas y notaciones a usar.

3.Describir el proceso de análisis: pasos a seguir y sus entregables/productos.



Documento de requerimientosLos requisitos establecidos explícitamente se reflejan

en el documento de especificación de requisitos del sistema:

Requerimiento: Un requerimiento puede ser especificado desde una sentencia en lenguaje natural, hasta en un lenguaje matemático muy formal. La línea entre requerimientos y especificaciones de diseño es delgada.

Las especificaciones de requerimientos deberían producirse a diferentes niveles de abstracción tomando en cuenta que una Especificación del Sistema debe ser entendida por los potenciales usuarios, de forma que sirva de base para realizar el contrato entre el ingeniero y los usuarios, quienes prefieren una descripción abstracta y a más alto nivel que la especificación para el contrato.Carrera de Sistemas&Informática

UMSS: Cochabamba-Bolivia12

Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software

¿Qué es un requerimiento?

DEFINICIÓN: Un servicio que el sistema debe proveerUna característica o restricción que debe

cumplir.

Ejemplos.. •No es una necesidad No es una necesidad •No es un problemaNo es un problema



Tipos de requerimientosFuncionales: funciones a realizar por el

software. Son declaraciones de los servicios que proveerá el sistema. Estos requerimientos son el corazón del sistema, puesto que su existencia explican la necesidad del mismo.

Algunas veces los requerimientos funcionales también declaran explícitamente lo que el sistema no debe hacer.

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.

Este es el corazón del sistema, si no fuera por los requerimientos funcionales, el sistema no tendría razón de ser.



Ej: requerimientos funcionales

Sistema de cajero automático. RF1: Identificar usuario. RF2: Emitir estado de cuenta. RF3: Realizar transacción de retiro de

dinero RF5: Emitir recibo impreso.



Tipos de requerimientosNo funcionales: Son restricciones bajo las

cuales el sistema debe operar.Aquellos requerimientos que no se refieren directamente a las

funciones específicas que entrega el sistema, sino a las propiedades emergentes de este como la fiabilidad, la respuesta en el tiempo, la capacidad de almacenamiento, interfaz, documentación, consideraciones de hardware, características de desempeño, manejo de errores, condiciones extremas, asuntos de calidad, modificaciones al sistema, ambiente físico, cuestiones de seguridad, cuestiones de recursos, políticas de la organización en cuanto al software o hardware

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema

Estos deben ser cumplidos, acompañan al sistema en sí para que sea usado.

Por ejemplo: Si pedimos que un sistema sea hecho en un administrador de BD determinado y no lo hacemos el usuario no hará uso de él porque la BD de la empresa esta sobre ese administrador



Más sobre requerimientosRequerimiento de usuario:

Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema.

Hay que tomar en cuenta que el usuario no posee un conocimiento técnico detallado

Especifican el comportamiento externo del sistema.Los requerimientos del usuario no se deben definir

utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos

Debido al lenguaje no formal para la especificación pueden surgir problemas como: falta de claridad o detalle, ambigüedades y otros relacionados con el lenguaje natural.



Más sobre requerimientosRequerimientos del sistema

Son descripciones más detalladas y formales que los requerimientos del usuario.

Agregan detallan y explican como el sistema debe proporcionar los requerimientos del usuario

Sirven como base para definir el contrato de la implementación del sistema y por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

Simplemente deben describir el comportamiento externo del sistema y sus restricciones operativas



Diagrama de Relaciones de los Conceptos dados

Se detallan



Cualidades RequerimientosDel documento de Esp. de Requerimientos

CompletoConsistente: Los requerimientos no tienen conflictos entre si

DocumentadoModificable: Su estructura facilita los cambios.

De un requerimientoCorrectoVerificable: debe poder definirse si se cumplió o no. sistema.Válido: lo que el usuario realmente quiere

No ambiguo: una sola interpretación

Documentado



¿Gestión de Requerimientos?Un Clásico…..

La solicitud de usuarioLo que entendió el líder

del proyectoEl diseño del analista de

sistemasEl enfoque del programador

La recomendación del consultor externo

La documentación del proyecto

La implantación en producción El soporte operativo

El presupuesto del proyecto

Lo que el usuario realmente necesitaba

¿ Necesario hacer gestión de requerimientos ?•Los requerimientos son los cimientos de un sistema•Los requerimientos son el “cuello de botella” de la Ing. de Software

Análisis - Subactividad: Modelado del sistema

Cubo de Agua

Nido de pájaros

La construcción del Watercube inició en diciembre de 2003 y se planea que esté completamente terminado a principios de 2007. Cinco piscinas, luz natural, acopio de agua de lluvia, reciclado del agua. Costo mas de 100 millones de dólares



Modelado del sistema ¿Cuándo se realiza esta actividad dentro del proceso

de desarrollo de software que se definió en la parte 1.?Actividades de Análisis y Diseño.

¿Que modelos existen y cómo se representan?Modelos de contexto: Estructurado (DFD de nivel

O), OO (Caso de uso general), Modelos comportamiento: OO ( diagrama de casos

de uso, diagrama de secuencia, diagrama de actividad), Estructurado: DFD’s

Modelos de datos: OO: Diagrama de clases. Estructurado: E-R



Modelado del sistema Modelos: ¿para qué sirven ?

Para describir el sistema formalmente

Cuándo usar ?Los modelos se utilizan en la actividad de

análisis y diseño. Los modelos ayudan a comprender el sistema/requerimientos /diseño y se deben usar cuando sea difícil la compresión sin ellos o la especificación pueda dar lugar a ambigüedades.

Los modelos ayudan a manejar la complejidad del sistema



Técnicas de relevamiento (recolección) de informaciónEntrevista.- Se selecciona a un conjunto de personas que represente

a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

Cuestionarios.- Consiste en el llenado formularios o contratos indicando los requerimientos. En sistemas muy complejos éstos pueden tener centenares de páginas. Y se usan cuando hay muchos usuarios, y es difícil entrevistarlos a todos.

Talleres.- Reuniones con varios usuarios para concertar requerimientos. Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma.

ObservaciónRevisión documental





Técnicas/HerramientasPrototipos.- Un prototipo es una pequeña muestra, de

funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de Uso.- Un caso de uso es una técnica para documentar posibles requerimientos, graficando la relación del sistema con los usuarios u otros sistemas.

DFD’s



Fuentes de informaciónPersonas:

Usuarios directos e indirectos del sistema Colegas con experiencia

Otros sistemasInternetDocumentos de la empresaLibros relacionados con el software a construir

De todas estas fuentes las personas son la fuente más relevante .



Repaso 2: Análisis (tarea 2)

1. Contrastar/relacionar/definir: Mejor si muestran mediante un diagrama las relaciones/diferencias entre los siguientes conceptos

2. Requerimientos funcionales -Requerimientos no funcionales-Requerimientos Usuario- Requerimientos del Sistema

3. De ejemplos por cada concepto de arriba 4 ejemplos aplicados a un sistema que le gustaría desarrollar

4. Modelado del sistema : Cuando se realiza esta actividad dentro del proceso de

desarrollo de software que se definió en la parte 1.? Que modelos existen ? Para qué sirven ? Cuándo usar ? Como se representan?



Tarea 3

El documento de especificación de requerimientos

1.-Introducción ir Propósito del documento de

requerimientos Alcance del producto

2.-Descripción general Perspectiva del producto Funciones del producto Restricciones generales Características del usuario

3.-Requerimientos específicos Requerimientos funcionales ir Requerimientos no funcionales

ir

4.- Alcance5.- Apéndice e índice ir

1. Introducción/Contexto

2. Requerimientos funcionales&No funcionales

3. Usuarios/roles: Indirectos/directos

4. Alcance

5. Anexos: Documentación, procedimientos, información sobre valores usados, validación.

PlanCarrera de Sistemas&Informática UMSS: Cochabamba-Bolivia


IntroducciónLa introducción debe introducir al tema que en

este caso es el sistema. Se debe hablar de la institución, sus objetivos

planes y como el sistema ayudará a lograrlos.Se debe establecer los objetivos de la institución

a largo, mediano y corto plazo y dentro de ese contexto establecer el lugar que tendrá el sistema.

Es importante ubicar al sistema en el ámbito de la organización.

Doc



Apéndices (anexos) e IndicesApéndice provee información detallada y precisa

relacionada con la aplicación que se desarrolla Todo lo que no se especificó en la parte principal de forma

detallada y da lugar a doble interpretación debe ser aclarado y especificado en los anexos. Es aquí que se debe DOCUMENTAR el análisis, es decir: se deben poner copias u originales de documentos como ser formularios de registro de datos, reportes, resúmenes que actualmente utilizan en la empresa (sean estos de origen manual o de del antiguo sistema automatizado que se desea cambiar), definir las características de los datos de los mismos, especificar procedimientos y/o cambios en los mismos.

Índice se debe incluir varios índices en el documento uno alfabético, de contenido, diagramas, funciones y otros.

DocCarrera de Sistemas&Informática UMSS: Cochabamba-Bolivia


Repaso Doc.Req. (tarea 3)

1. Especifique el contenido mínimo. Explique mediante un ejemplo en que consiste cada una de sus partes ( a través de un caso de aplicación).

2. Indique que fuentes de información son recomendables para su elaboración y en que consiste cada una de ellas.

3. Condiciones que tiene que cumplir o características que debe tener el documento para ser considerado de calidad.

4. Mencione el contenido de los anexos que debería tener este documento.



Análisis de FactibilidadAnálisis de opciones

Análisis de factibilidadObjetivo Resultados

Es asegurarnos que el proyecto va traer

beneficios y es posible realizarlo con los recursos

materiales, tecnológicos y

humanos

•Seguir adelante con el proyecto•Recomendar retrasar por un tiempo•No continuar con el proyecto•Continuar con el proyecto modificado



Análisis de factibilidadConsideraciones:

Factibilidad económica (administrador de la empresa): Beneficios $ Vs. Costos $

Factibilidad técnica (desarrollador/administrador)

Factibilidad operativa (desarrollador)

Factibilidad legal (desarrollador)

Factibilidad políticaCarrera de Sistemas&Informática UMSS: Cochabamba-Bolivia


Análisis de opcionesObjetivo

Es escoger el proyecto que más ventajas tiene .Producto

Informe indicando la mejor opción y por quéSe necesita establecer:

1.Objetivos & Prioridades 2.Establecer parámetros de comparación 3.Cuantificar los parámetros elegidos para cada una de las opciones4.Aplicar algún método para elegir objetivamente una opción.

MétodosMatriz pay-offGráficos de polaridad



Análisis de opciones: Matriz Pay-off

1. Opción conservativa: objetivo minimizar las pérdidas, elegirá la opción con payoff más bajo: 15.000.

2. Opción optimista: el objetivo de maximizar las ganancias, elegirá la opción con payoff más grande: opción A.

Sin embargo ni la opción conservativa, ni la optimista toma las en cuenta las magnitudes relativas de las ganancias o las pérdidas, por lo que se

planteó la siguiente:

3.

Opción Costo Máximo ($)

Costo Mínimo

($)

Payoff($)

AB

100.00070.000

40.00055.000

60.000015.000



Análisis de opciones: Matriz Pay-offOpción minimización de riesgos: considera la misma

probabilidad para el máximo valor como para el mínimo, por ejemplo:Opción A: Costo probable = (0,5 x 100.000) + (0,5 x 40.000) =

70.000Opción B: Costo probable = (0,5 x 70.000) + (0,5 x 55.000) =62.500

Por lo que de acuerdo a esta tercera opción escogeríamos la de menor riesgo la opción B con 62.500.

Si se conociese la probabilidad para A que se de el mínimo, por ejm. 65%. Y para B la probabilidad de mínimo, por ejm. 45%Opción A: Costo probable = (0,35 x 100.000) + (0,65 x 40.000) = 61.000 Opción B: Costo probable = (0,55 x 70.000) + (0,45 x 55.000) = 63.250

Por lo que en este caso la opción A sería la escogida puesto que permite minimizar riesgos.



Análisis de opciones: Gráfico de polaridadOpció

nCostoMiles Bs.

Calendario(meses)

Confiabilidad

Reuso(%)

Portabilidad

Eficiencia

ABC

12.08.017.5

333036

5913

404050

907530

0.350.75

1

0,0

20,0

40,0

60,0

80,0

100,0Costo

Calendario

Confiabilidad

Reuso

Portabiliad

Eficiencia

A

B

C



Documents

Tarea 1 Conceptos Mgr. Indira Camacho del Castillo UMSS: Cochabamba - Bolivia