REQUISITOS DEL PROYECTO

INFORMTICO

ING. EDWIN CHUNGA

PROYECTO INFORMTICO

ING. EDWIN CHUNGA

Contenido:
1. Proyecto informtico
2. Cmo nace un proyecto
3. Un proyecto implica
4. Etapas de un proyecto

Logro:
Considerar los fundamentos de un proyecto informtico considerando la Ingeniera
de Software.

1. Proyecto informtico
Un proyecto de ingeniera de software es un proyecto cuyo objetivo es obtener un
producto de software que satisfaga ciertos requisitos, en el plazo previsto y dentro
del presupuesto. (Snchez, 2012)

2. Cmo nace un proyecto

Debido a un problema, una oportunidad, una necesidad genera una IDEA
Debemos Transformar esa idea en un OBJETIVO
Luego alcanzar ese objetivo obteniendo un PRODUCTO
Ese producto debe dar solucin al problema u oportunidad original.
Esto lo haremos travs de la realizacin de un proyecto dentro el marco de las
ORGANIZACIONES involucradas.

3. Un proyecto implica
Un problema (o un objetivo).
Un contexto.
Una forma de solucin.

4. Etapas de un proyecto

IDENTIFICACIN DEL NEGOCIO

ING. EDWIN CHUNGA

Pensemos un poco
Tal y como Brooks sugiere, la complejidad del software es una propiedad esencial,
no accidental. Observamos que esta complejidad inherente tiene que ver con
cuatro factores: la complejidad del dominio del problema, la dificultad para
gestionar el proceso de desarrollo, la flexibilidad que el software ofrece y los
problemas que caracterizan el comportamiento de los sistemas discretos.
Grady Booch

Modelar el negocio es la clave del xito del proceso de software ?

1. Realidad Actual del Negocio

Situacin actual del negocio.

2. Realidad Problemtica del Negocio

Problema del negocio

3. Objetivos del Negocio

Objetivos

4. Procesos de negocio
Un conjunto de actividades interrelacionadas de trabajo, cada cual con insumos y
rendimientos prescritos.
Tiene un principio y un fin bien definidos.

MODELADO DE NEGOCIO

ING. EDWIN CHUNGA

Contenido:
1. Actividades del negocio
2. Modelo de dominio

Logro:
Disear los artefactos del modelado del negocio considerando el lenguaje unificado
de modelado.

1. Actividades de negocio
Muestra un proceso de negocio o un proceso de software como un flujo de trabajo a
travs de una serie de acciones.
Es ideal para modelar el flujo de informacin entre roles participantes de un negocio.
En ellos se indica las actividades realizadas por cada uno, la relacin entre ellas y los
productos generados por estas. Tambin muestran los estados de los productos
mencionados y cmo estos cambian al ser afectados por las actividades
Elementos:
Inicio
Lnea de Transicin
Actividad o tarea
Decisiones
Fin

2. Modelo de dominio
Un modelo del dominio es una representacin visual de las clases conceptuales u
objetos del mundo real en un dominio de inters. Tambin se les denomina modelos
conceptuales, modelo de objetos del dominio y modelos de objetos de anlisis.
Puede utilizarse para capturar y expresar el entendimiento ganado en un rea bajo
anlisis como paso previo al diseo de un sistema.

Conclusiones
El modelo de dominio la visin global de la estructura del sistema actual.

OBTENCIN DE REQUISITOS

ING. EDWIN CHUNGA

Contenido:
1. Requisitos de software
2. Tipos de requisitos

Logro:
Identificar los requisitos de un sistema considerando la ingeniera de requisitos.

Pensemos un poco
Lo ms complicado de construir un sistema software es decidir exactamente qu
construir []. Ninguna otra parte del trabajo afecta tan negativamente al resultado
si se hace mal. Ninguna otra es tan difcil de rectificar.
F.F. Brooks

Modelar los requisitos es saber que hacer en lugar del como hacer?

1. Requisitos de software
Un requisito es simplemente una declaracin abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restriccin de ste. En el otro extremo, es
una definicin detallada y formal de una funcin del sistema (Sommerville).
Un requisito de software es la capacidad que debe alcanzar o poseer un sistema o
componente de un sistema para satisfacer un contrato, estndar, especificacin u
otro documento formal (IEEE, 1990)

2. Tipos de requisitos
Un requisito funcional especifica una funcin que un sistema o componente de un
sistema debe ser capaz de llevar a cabo.
Los requisitos no funcionales son aquellos que especifican aspectos tcnicos que debe
incluir el sistema, y que pueden clasificarse en restricciones y calidades.
Las Reglas del Negocio describen las polticas, normas, operaciones, definiciones y
restricciones presentes en una organizacin y que son de vital importancia para alcanzar
los objetivos misionales.

Conclusiones
Todo desarrollo de software parte de un requerimiento.
El modelado de requisitos es saber que hacer en un sistema.
Los requerimientos funcionales, no funcionales y la s reglas de negocio permiten
definir el modelado de requisitos.

Patrocinadores

Requerimient
os de
negocio

Usuarios
finales

Requerimien
tos de
usuario

Incrementar en un 20% los

ingresos anuales mediante un
software
Compra
r
Casos
boletos
de uso
en lnea

Equipo de
desarrollo

Requerimient
os
funcionales

El origen y destino del viaje

deben ser elegidos a partir de
un combo box

ESPECIFICACIN DE REQUISITOS

ING. EDWIN CHUNGA

Contenido:
1. Diagrama de casos de uso
2. Prototipos de interfaz grafica de usuario

Logro:
Elaborar la especificacin de requisitos de un sistema considerando el Lenguaje
Unificado de Modelado.

1. Diagrama de casos de uso

Es la descripcin de un conjunto de secuencias de acciones que ejecuta un sistema
para producir un resultado observable con valor significativo para un observador
externo.
Se utilizan para mostrar la funcionalidad que el sistema ofrecer y que usuarios se
comunicaran con el sistema para utilizar esa funcionalidad.
Permiten definir los limites del sistema y las relaciones entre el sistema y el
entorno

2. Prototipos de interfaz grfica de usuario

Un prototipo es un modelo fcilmente ampliable y modificable de un sistema
software donde se muestra su interfaz y las funcionalidades de entrada-salida ms
relevantes.
El prototipo consiste en la elaboracin de un modelo del sistema que se construye
para evaluar mejor sus requisitos

Conclusiones
Los diagramas de casos de uso especifican el que en lugar del como.