Resumen del tema

E n l a a c t u a l i d a d e n l a i n d u s t r i a d e l S o f t w a r e e x i s t e u n a t e n d e n c i a a l c r e c i m i e n t o d e l v o l u m e n y c o m p l e j i d a d d e l o s p r o d u c t o s , y s e e x i g e m a y o r c a l i d a d y p r o d u c t i v i d a d e n m e n o s t i e m p o . E l p r o c e s o d e d e s a r r o l l o d e s o f t w a r e s e e n c a r g a d e t r a d u c i r l a s n e c e s i d a d e s d e l u s u a r i o e n r e q u e r i m i e n t o s d e S o f t w a r e . L a i n g e n i e r í a d e S o f t w a r e s e c o n s i d e r a l a r a m a d e l a i n g e n i e r í a . L a c o m p u t a c i ó n y l a s m a t e m á t i c a s p a r a l o g r a r s o l u c i o n e s c o s t o e f e c t i v a s a l o s p r o b l e m a s d e d e s a r r o l l o d e S o f t w a r e , e s d e c i r , p e r m i t e

e l a b o r a r c o n s i s t e n t e m e n t e p r o d u c t o s c o r r e c t o s , u t i l i z a b l e s y c o s t o s - e f e c t i v o s . L a m i s m a r e q u i e r e l l e v a r a c a b o v a r i a s t a r e a s , u n a d e e l l a s e l a n á l i s i s d e r e q u i s i t o s . E l a n á l i s i s d e r e q u i s i t o s p e r m i t e e x t r a e r l o s r e q u i s i t o s .

Debemos intentar entender qué tipo de requisitos pueden aparecer en la fase de educción de requisitos y qué tipo de requisitos se esperan del sistema de software. En líneas generales los requisitos de software se deben caracterizar en dos categorías: Requisitos funcionales Requisitos no funcionales

Requisitos que se relacionan a aspectos funcionales del software irían en esta categoría. Definen las funciones y la funcionalidad en y desde el sistema de software. Ejemplos: Buscar una opción dada al usuario para buscar desde varias facturas. Debe cumplir reglas empresariales y funciones administrativas.

Los cuales no están relacionados con aspectos funcionales del software, están en esta categoría. Son características del software implícitas o esperadas, asumidas por los usuarios. Los requisitos no funcionales incluyen: Seguridad

El análisis de sistemas es una de las etapas de construcción de un sistema informático, que consiste en relevar la información actual y proponer los rasgos generales de la solución futura. Las razones para iniciar un análisis de sistema son: La necesidad de resolver un problema. Las nuevas necesidades.

Eficacia en el sistema actual. Ideas de diseño. Reconocimiento de recursos. Conocimiento de conversión.

Papeleo dentro de la organización o documentación.

Entrevista. Cuestionario. Observación.

Las técnicas de recolección de datos se definen como el conjunto de procedimientos y herramientas para recoger, validar y analizar la información necesaria que permita lograr los objetivos de la investigación. Las principales son: La Observación La Entrevista La Encuesta

Directa Indirecta La participante

La estructurada o formal la no estructurada o informal La semi estructurada

Llamamos captura de requisitos al acto de descubrir o averiguar en circunstancias difíciles lo que se debe construir.

La fase de captura de requisitos tiene como objetivo descubrir y recoger todos y cada uno de los requisitos funcionales y no funcionales de la aplicación a definir de forma clara y concisa.

Para el éxito en la captura de requisitos el analista funcional necesitará poner en práctica distintas técnicas y probablemente varias iteraciones de este proceso, de forma que se vallan refinando y completando los requisitos obtenidos. Estudio de documentación existente Entrevistas con las distintas personas y roles involucrados en el proyecto

Talleres o sesiones de trabajo Observación Prototipado Cuestionarios

Cada proyecto de Software nunca es igual y contiene diferencias en el sistema donde el cliente puede identificar diferentes puntos de partida para empezar con la captura de los requisitos. Las metodologías de desarrollo de software son un conjunto de técnicas y métodos organizativos que se aplican para diseñar soluciones de software informático.

Modelo de cascada: es una metodología en la que las etapas se realizan de arriba a abajo, de ahí el nombre. Se desarrollan de forma diferentes obedeciendo un rigoroso orden.

Modelo de prototipado : se basa en la construcción de un prototipo de Software que se construye rápidamente para que los usuarios puedan probarlo y aportar feedback.

Modelos Incremental: se va construyendo el producto final de una manera progresiva. En cada etapa incremental se agrega una nueva funcionalidad, lo que permite ver resultados de una forma mas rápida.

Modelo de negocio: describe el modo en que una organización crea, distribuye y captura atención de un segmento de mercado hacia el cliente. Construir el modelo de negocios, inicial que es una descripción de los procesos de la empresa. Entrevistas: Estructuradas No estructuradas

Entrevistas estructuradas: se definen como herramientas de investigación que son extremadamente rígidas en sus operaciones , y permiten muy poco o ningún margen de incitar a los participantes a obtener y analizar los resultados. No estructuradas: suelen describirse como conversaciones con un propósito en mente recopilar datos sobre el estudio de investigación.

Cuestionario Formularios

Un modelo de dominio es una representación de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades (Larman, 2002)

Objetos del dominio o clases conceptuales Asociaciones entre las clases conceptuales Atributos de las clases conceptuales

Ventana Bases de datos Responsabilidades o métodos

Identificar y representar conceptos del dominio de problema. Establecer y entender las relaciones entre los conceptos. Identificar atributos de cada concepto. Representar entidades de negocio en el modelado de proceso.

Símbolo: palabras o imágenes que representan una clase conceptual Intensión: la definición de una clase conceptual Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual

Conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes.

La validación de los requisitos, obviamente tiene como objetivo comprobar que estos son correctos.

Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos.

Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.

Asegura una entrevista, fructífera: con la entrevista construyes los cimientos para una buena propuesta.

Presentar una buena propuesta de proyecto de software aumenta significativamente las posibilidades de vender tus proyectos como freelance, pero también estás adquiriendo un hábito profesional que proyecta mucho valor.

¿Cual es su nicho del mercado? ¿Con que presupuesto cuenta? ¿En cuanto tiempo lo necesita?

1. "Quiero salir adelante de tantos problemas,...….¡Necesito un software ajustado a mi empresa! 2. "Ya hablamos sobre lo que necesito y urgente ¿podemos discutir precios? 3. "¡Que costoso! Yo solo quiero algo para manejar y exportar inventario ¡eso es algo sencillo!

Captura de Requisitos podemos decir que Exististe dos tipos de requisitos los cuales son; funcionales y No funcionales. Los análisis de sistema es una de las etapas de construcción de un sistema informático, que consiste en revelar la información actual. La recolección de datos consta de procedimientos y herramientas para recoger, analizar y validar la información que será necesaria para la organización. La captura de requisitos candidatos es aquella que va de acorde con el proyecto y facilita su función.