el proceso de software 2k7-2k10 - 2015 (1)

8/19/2019 El Proceso de Software 2K7-2K10 - 2015 (1)

1/25

El Proceso de Desarrollo de Software

Análisis de Sistemas – Curso: 2K7 – 2K10

Unidad: 2

- Diapositivas de clases -

Docente: Ing. Marcela F. Cattaneo

JTP y Ay: Ing. María Irene Mac William2K7 Ing. Germán Vélez

JTP y Ay: Ing. Claudia Sánchez2K10 Ing. Susana Turanzas

2

Ingeniería

de

Software:Conceptos BásicosParadigma: • El historiador Thomas Khun definió la palabra

paradigma como “un conjunto de teorías, estándaresy métodos que juntos representan una forma deorganizar el conocimiento, es decir, una forma de verel mundo”

• Es un modelo, teoría, marco de referencia, o filosofía,es alguna manera o forma en la cual vemos el mundo,no en términos del sentido de la vista, sino entérminos de percepción, interpretación,entendimiento. Es una estructuración delpensamiento: estructura la forma de ver las cosas.

ASI ‐ El Proceso de Desarrollo de Software


2/25

3

Ingeniería de Software:

Conceptos

BásicosParadigma: • Es una filosofía que considera métodos, herramientas y

procedimientos, y que permiten al profesional desistemas tener una forma clara, confiable y generalizadade desarrollar un sistema de información. Trabaja comoun filtro: pone límites, nos permite resolver problemasdentro de esos límites.

• Para el estudio de los sistemas de información tenemosdos paradigmas (dos formas de “ver” y modelar unsistema):

– El Paradigma Estructurado (que pone énfasis en las funciones) y – El Paradigma Orientado a Objetos (que pone énfasis en los

objetos)


4

Ingeniería

de

Software:Conceptos BásicosIngeniería de SoftwareEn una conferencia sobre el tema, Fritz Bauer dio la siguiente

definición:

• “La ingeniería de software es el establecimiento y uso deprincipios robustos de la ingeniería a fin de obtenereconómicamente software que sea fiable y que funcioneeficientemente en máquinas reales”

• El IEEE define “La Ingeniería de software como (1) laaplicación de un enfoque sistemático, disciplinado ycuantificable hacia el desarrollo, operación ymantenimiento del software, es decir la aplicación deingeniería al software, (2) El estudio de enfoques como en(1).”



3/25

5


Capas• La ingeniería de software es una tecnología multicapa.

Cualquier enfoque de ingeniería, incluso la ing. desoftware, debe buscar siempre un enfoque de calidad.

Gráfico Capas de la ingeniería de software:. .

. Herramientas .. Métodos .

. Proceso . .

Enfoque

de

calidad

.Los cimientos que son la base de la ing. de software están

orientados hacia la calidad.


6

Ingeniería

de

Software:CapasProceso:• Es la unión que mantiene juntas las capas de

tecnología y permite un desarrollo racional de laIng. de Software.

• Define un marco de trabajo para un conjunto deÁreas Claves del Proceso (ACPs), determinandodistintas actividades aplicables a todos los

proyectos de software, independientemente desu tamaño y complejidad.



4/25

7


CapasProceso:• Las ACP (Áreas Claves del Proceso ) forman la

base del control de gestión de proyectos desoftware, establecen el contexto en el que – se aplican los métodos técnicos,

– se producen resultados del trabajo (modelos,documentos, datos, informes, formularios, etc.),

– se establecen hitos,

– se asegura la calidad y

– se gestiona el cambio.


8

Ingeniería

de

Software:CapasMétodos: • Indican cómo construir técnicamente un sistema.

Abarcan un amplio espectro de tareas: – planificación y estimación de proyectos

– análisis de los requisitos

– diseño, construcción de programas

– prueba y mantenimiento.

• Dependen de un conjunto de principios básicos que

gobiernan cada área de la tecnología e incluyenactividades de modelado y otras técnicas descriptivas.

• Cabe destacar que se llama Técnica a un métodoestructurado y repetible para lograr una tareaespecífica.



5/25

9


CapasHerramientas:• Suministran un soporte automático o semiautomático

para el proceso y los métodos.

• Cuando se integran herramientas para que lainformación creada por una herramienta la puedautilizar otra, se establece un sistema de soporte para eldesarrollo del software llamada Ingeniería de SoftwareAsistido por Computadora (CASE), que combinahardware, software y bases de datos conteniendoinformación importante sobre el análisis, diseño,

construcción y prueba de sistemas.• Las herramientas son principalmente gráficas,

trabajaremos mucho con modelos.ASI ‐ El Proceso de Desarrollo de Software

10

Ingeniería

de

Software:CapasModelo:• Es una representación simplificada de la

realidad, un modelo proporciona los planos deun sistema.

• Un buen modelo incluye aquellos elementosque tienen una gran influencia y omite aquellosmenores que no son relevantes para el nivel de

abstracción dado.• Todo sistema puede ser descripto desde

diferentes perspectivas utilizando diferentesmodelos.



6/25

11


CapasModelo:• Se construyen modelos para comprender mejor

el sistema que estamos desarrollando. A travésdel modelado se persiguen los siguientesobjetivos: – Los modelos ayudan a visualizar cómo es o queremos

que sea un sistema.

– Los modelos permiten especificar la estructura o elcomportamiento de un sistema.

– Los modelos proporcionan plantillas que sirven deguía en la construcción de un programa.

– Los modelos documentan las decisiones que se hanadoptado.ASI ‐ El Proceso de Desarrollo de Software

12

El Proceso de Software

El proceso del software se puede caracterizar como

en la siguiente figura:

Actividades de Protección

Marco de Trabajo del Proceso común

Actividades del marco de trabajo

Conjunto de tareas

Tareas

Hitos, entregas

Puntos SQA

Actividades de Protección

Marco de Trabajo del Proceso común

Actividades del marco de trabajo

Conjunto de tareas

Tareas

Hitos, entregas

Puntos SQA

ASI - El Proceso de Desarrollo de

SoftwareProceso


7/25

13

El Proceso de Software• Se establece un marco común del proceso, definiendo

un pequeño número de actividades del marco detrabajo que son aplicables a todos los proyectos desoftware.

• Un conjunto de tareas – cada uno es una colección detareas de ing. de soft., hitos de proyectos, posiblesentregas y puntos de garantía de calidad – que permitenque las actividades del marco de trabajo se adapten alproyecto de software y a los requisitos del equipo deproyecto.

• Las actividades de protección son independientes de

cualquier actividad del marco de trabajo y aparecendurante todo el proceso (garantía de la calidad delsoftware, gestión de la configuración del software,medición).


14

El Proceso

de

Software

• El SEI (Instituto de Ingeniería de Software) hadesarrollado un modelo completo que se basaen un conjunto de funciones de ingeniería desoftware que deberían estar presentes conformelas organizaciones alcanzan diferentes niveles demadurez del proceso.

• CMM Modelo de Capacidad de Madurez(Capability Maturity Model)



8/25

15

El Proceso de Software

CMM Establece cinco niveles de madurez delproceso:


16

El Proceso

de

Software

CMM Establece cinco niveles de madurez delproceso:

• Nivel 1: Inicial – Se definen pocos procesos, el éxito dependedel esfuerzo individual.

• Nivel 2: Repetible – Se establecen procesos de gestión, parahacer seguimiento de costos, de la planificación y de lafuncionalidad.

• Nivel 3: Definido – Proceso documentado y estandarizado, +características de Nivel 2

• Nivel 4: Gestionado – Se recopilan medidas detalladas delproceso de soft. y de la calidad del producto, + característicasde Nivel 3

• Nivel 5: Optimización – Mediante un resultado cuantitativodel proceso de las ideas y tecnologías innovadoras se mejorael proceso, + características de Nivel 4



9/25

17

Proceso de Desarrollo

Concepto

• Un proceso de desarrollo de software es elconjunto de actividades necesarias paratransformar los requisitos de un usuarioen un sistema software.

Proceso de

Desarrollode softwareRequisitos delusuario

Producto Software


18

Proceso de

Desarrollo

Las cuatro “P” en el desarrollo de software

• Personas

• Proyecto

• Producto

• Proceso

Proceso

Proyecto

Producto

Personas

Plantilla

Participantes

Resultado



10/25

19


Las

cuatro

“P”

en

el

desarrollo

de

software• Personas: Los principales autores del

proyecto son – Los arquitectos, desarrolladores, ingenieros de

prueba y el personal de gestión que les dasoporte, además de los usuarios, clientes y otrosinteresados.

– Hay personas implicadas en el desarrollo de unproducto de software durante todo su ciclo devida:

• Financian el producto, lo planifican, lo desarrollan, logestionan, lo prueban, lo utilizan y se benefician con él.


20

Proceso

de

DesarrolloLas cuatro “P” en el desarrollo de software

• Proyecto: Elemento organizativo a travésdel cual se gestiona el desarrollo delsoftware. El resultado de un proyecto esuna versión del producto.

– A través del ciclo de vida, un equipo deproyecto debe preocuparse del cambio, lasiteraciones y el patrón organizativo dentro delcual se conduce el proyecto.



11/25

21


Las

cuatro

“P”

en

el

desarrollo

de

software

• Producto: Artefactos que se creandurante la vida del proyecto, como losmodelos, código fuente, ejecutables ydocumentación.

– El producto es más que el código, hacereferencia al sistema entero y no sólo al

código que se entrega.


22

Proceso

de

DesarrolloLas cuatro “P” en el desarrollo de software• Proceso: Es una definición del conjunto

completo de actividades necesariaspara transformar los requisitos de unusuario en un producto. – Un proceso es una plantilla para crear

proyectos.

– Es una definición de un conjunto deactividades, no su ejecución.



12/25

23


Propósitos• Uno de los problemas del software se debe

a la dificultad que afrontan losdesarrolladores para coordinar las múltiplescadenas de trabajo de un gran proyecto.

• La comunidad de desarrolladores necesitauna forma coordinada de trabajar. Necesitaun proceso que integre las múltiples facetas

del desarrollo.


24

Proceso

de

DesarrolloPropósitosLos desarrolladores necesitan un proceso que

• Proporcione una guía para ordenar lasactividades de un equipo.

• Dirija las tareas de cada desarrollador porseparado y del equipo como un todo.

• Especifique los artefactos / modelos /

especificaciones que deben desarrollarse.• Ofrezca criterios para el control y la medición

de los productos y actividades del proyecto.



13/25

25


• La descomposición del proceso se realiza hastael nivel de tareas o actividades elementales.

• Para cada tarea se identifica un procedimientoque define la forma de ejecutarla, y es elvehículo de comunicación entre usuarios ydesarrolladores (personas), como resultado deseguir un procedimiento se obtienen uno o másproductos.

• El sistema deseado está constituido por unconjunto de productos finales.


26

Proceso de

Desarrollo

Actividades genéricas en todo Proceso deDesarrollo de Software:

• DEFINICION

• DESARROLLO

• MANTENIMIENTO



14/25

27


DefiniciónSe centra sobre el QUÉ, es decir, identificar los requisitosclaves del sistema de información detectando:• Información necesaria a ser procesada• Qué comportamiento y rendimiento se desea del

sistema• Qué interfaces van a ser establecidas• Qué restricciones de diseño existen y• Qué criterios de validación se necesitan para definir

un sistema correcto.Se pueden determinar tres tareas fundamentales:

– Ingeniería de sistema o de información – Planificación del proyecto de software – Análisis de requisitosTambién se crean los modelos necesarios, aplicando métodos yherramientas correspondientes.ASI ‐ El Proceso de Desarrollo de Software

28

Proceso

de

DesarrolloDesarrolloSe centra en el CÓMO:

• Cómo diseñar las estructuras de datos y la arquitectura del software

• Cómo implementar los detalles más elementales

• Se agregan aspectos de implementación y tecnología

• Cómo traducir el diseño a un lenguaje de programación y

• Cómo realizar la prueba.

Tareas fundamentales:

• Diseño del software

• Codificación

• Prueba



15/25

29


MantenimientoSe centra en el CAMBIO que va asociado a:• La corrección de errores y/o adaptaciones por:

– Modificaciones en el entorno o – Por requisitos cambiantes del usuario.

La fase de mantenimiento vuelve a aplicar los pasos de lasfases definición y de desarrollo en el contexto del softwareya existente. Se encuentran cuatro tipos de cambio:

• Corrección• Adaptación• Mejora• Prevención


Comunicación :-Inicio del Proyecto- Recopilación de

requisitos

Planeación:-Estimación- Itinerario- Seguimiento

Modelado:-Análisis- Diseño

Construcción:

- Codificación- Prueba

Despliegue:-Entrega

- Soporte- Retroalimentación

Comunicación :-Inicio del Proyecto- Recopilación de

requisitos

Planeación:-Estimación- Itinerario- Seguimiento

Modelado:-Análisis- Diseño

Construcción:

- Codificación- Prueba

Despliegue:-Entrega

- Soporte- RetroalimentaciónModelo en Castada ‐ Fuente: Libro “Ingeniería del Software” –

Roger Pressman, Pág. 50.

Comunicación

Planeación

Modelado (análisis, diseño)

Construcción (codificación, prueba)

Despliegue (entrega,retro alimentación)

F u n c i o n a l i d a d y c a r a c t e r í s t i c a s d e l s o f t w a r e

iempo decalendaro deproyecto

Incremento #1

Entregadelprimer incremento

Incremento #2

Entregadelsegundo incremento

Incremento #n

Entregadeln-ésimoincremento

Comunicación

Planeación




Comunicación

Planeación




F u n c i o n a l i d a d y c a r a c t e r í s t i c a s d e l s o f t w a r e

iempo decalendaro deproyecto

Incremento #1


Incremento #1


Incremento #2


Incremento #2


Incremento #n


Incremento #n


Modelo Incremental ‐ Fuente: Libro “Ingeniería del Software” – Roger Pressman, pág. 52.

Comunicación

Planeación

Despliegue :-Integración-Entrega

-Retroalimentación

Modelado :-Modelado del negocio-Modelado de losdatos-Modelado del proceso

Construcción:

-Reutilización decomponentes

-Generación automáticade código

-Pruebas

Equipo # 1


Construcción:-Reutilización de

componentes-Generación automáticade código

-Pruebas

Equipo # 2

Modelado :-Modelado del negocio-Modelado de losdatos

-Modelado del proceso


componentes-Generaciónautomáticade código

-Pruebas

Equipo # n

60 –90 días

Comunicación

Planeación

Despliegue :-Integración-Entrega

-Retroalimentación


Construcción:



-Pruebas


Construcción:



-Pruebas

Equipo # 1




-Pruebas

Equipo # 2




-Pruebas




-Pruebas

Equipo # 2





-Pruebas

Equipo # n





-Pruebas





-Pruebas

Equipo # n

60 –90 días

Modelo DRA - Fuente: Libro “Ingeniería del Software” –

Roger Pressman, pág. 54.

Modelos de Procesos

Incrementales

ComunicaciónPlan rápido

ModeladoDiseño rápido

Construccióndel prototipo

DesarrolloEntrega y

retroalimentación

ComunicaciónPlan rápido

ModeladoDiseño rápido

Construccióndel prototipo

DesarrolloEntrega y

retroalimentación

Modelo Construcción de Prototipos ‐ Fuente: Libro “Ingeniería del Software” –Roger Pressman, pág. 55

Modelo en espiral ‐ Fuente: Libro “Ingeniería del Software” –Roger Pressman, pág. 58.

Modelos de Procesos

Evolutivos

Procesos

de

Desarrollo

conocidos

30ASI ‐ El Proceso de Desarrollo de Software


16/25

Fuente:http://agilemodeling.com/essays/agileModelingRUP.htm

PUD (Proceso Unificado de Desarrollo)

Inicio E labor ac ión C onstr uc ción T ra nsic ión

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Prueba

Implementación

Diseño

Análisis

Requisitos

Fases

Flujos de trabajo

fundamentales

Iteraciones

Inicio E labor ac ión C onstr uc ción T ra nsic ión

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Prueba

Implementación

Diseño

Análisis

Requisitos

Fases

Flujos de trabajo

fundamentales

Iteraciones

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, pág. 11.

Agile

UnifiedProcess(AUP).

Rational Unified Process (RUP)

http://www.ts.mah.se/RUP/RationalUnifiedProcess/

El PUD y sus variantes


SCRUM

XP (Extreme Programming)

Fuente: http://www.roggerocorp.com/impacto ‐de‐metodologias ‐agiles‐scrum‐kanban‐en‐las‐organizaciones/

KANBAN

Fuente: http://www.extremeprogramming.org/map/project.html

Fuente: http://comunidad.iebschool.com/iebs/general/metodologia ‐kanban/

Procesos Ágiles



17/25

33

PUD – Proceso Unificado de Desarrollo

• El Proceso Unificado es un proceso dedesarrollo de software que utiliza elLenguaje Unificado de Modelado (UML)para preparar todos los esquemas de unsistema de software.

• Características esenciales de PUD: – Dirigido por casos de uso

– Centrado en arquitectura

– Iterativo e incremental


PUD

Inicio E laboración Const rucc ión Tr ansición

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Versiones

Inicio E laboración Const rucc ión Tr ansición

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Versiones

ASI ‐ El Proceso de Desarrollo de Software 34

• Ciclo de vida del Proceso Unificado


18/25

PUD

X

OK

X

OK

X

OK

Modelo de

Casos de Uso

Modelo de Análisis

Modelo de Diseño

Modelo de Despliegue

Modelo de

Implementación

Modelo de Prueba

Especificado por

Realizado por

Distribuído por

Implementado por

Verificado por

X

OK

X

OK

X

OK

X

OK

X

OK

X

OK

Modelo de

Casos de Uso

Modelo de Análisis

Modelo de Diseño

Modelo de Despliegue

Modelo de

Implementación

Modelo de Prueba

Especificado por

Realizado por

Distribuído por

Implementado por

Verificado por


• Modelos del PUD

PUD

Inicio Elaboración Construcción T ransición

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Prueba

Implementación

Diseño

Análisis

Requisitos

Fases

Flujos de trabajo

fundamentales

Iteraciones

Inicio Elaboración Construcción T ransición

Iteración

# n-1

Iteración

# nIteración

# 2 ...

Iteración

# 1- - - - - - - - - - - - - - -

Prueba

Implementación

Diseño

Análisis

Requisitos

Fases

Flujos de trabajo

fundamentales

Iteraciones


• Fases del Proceso Unificado


19/25

PUD


Conceptos básicos

del

proceso

– Flujo de Trabajo (Workflow)

– Artefacto

– Trabajador

– Actividades

Arquitecto Prioriza r los

casosdeuso

Analistade

SistemasEncontraractores

ycasos deuso

Estructurar elmodelo

decasosdeuso

Especificador

deCasos

deUso

Detallarun

caso deuso

Diseñador

deInterfaz

deUsuario

Prototipar la

interfazdel usuario

Arquitecto Priorizar los

casosdeuso

ArquitectoArquitecto Priorizar los

casosdeuso

Priorizar los

casosdeuso

Analistade


ycasos deuso


decasosdeusoAnalistade

Sistemas

Analistade


ycasos deuso

Encontraractores

ycasos deuso


decasosdeuso


decasosdeuso

Especificador

deCasos

deUso

Detallarun

caso deuso

Especificador

deCasos

deUso

Especificador

deCasos

deUso

Detallarun

caso deuso

Detallarun

caso deuso

Diseñador

deInterfaz

deUsuario

Prototipar la

interfazdel usuario

Diseñador

deInterfaz

deUsuario

Diseñador

deInterfaz

deUsuario

Prototipar la

interfazdel usuario

Prototipar la

interfazdel usuario

Modelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de usoModelo de casos de uso

Analista Arquitecto

Descripción dela arquitectura

Encontrar Actoresy Casos de Uso

38

Estudio de

Prefactibilidad

• La factibilidad significa que el proyectopropuesto:

– Ayuda a que la organización logre susobjetivos generales.

– Es posible de lograr con los recursos actualesde la organización en estas tres áreas:

• Factibilidad Técnica• Factibilidad Económica

• Factibilidad Operativa



20/25

39

Estudio de Prefactibilidad

• Definición de objetivos: – La determinación de factibilidad en general significa

encontrar cuáles son los objetivos organizacionales yluego determinar si el proyecto sirve para mover elnegocio hacia sus objetivos en alguna forma.

– Algunos de esos objetivos organizacionales:• Reducir errores, mejorar la precisión y acelerar el ingreso de

datos.• Integrar los subsistemas del negocio.• Mejorar los servicios al cliente.• Acortar el tiempo de procesamiento de datos.

• Automatizar los procedimientos para mejorarlos de algunamanera (reducir errores, aumentar velocidad y precisión,disminuir tiempo de empleados requeridos, etc).


40

Estudio de

Prefactibilidad

• Determinación de recursos: – La determinación de recursos para el estudio

de factibilidad será revisado y vuelto a evaluarmás adelante en el proceso de desarrollo delsoftware.

– Los recursos serán tratados en relación contres áreas de factibilidad:

•Técnica• Económica

• Operativa



21/25

41


Factibilidad

Técnica• El analista debe determinar si los recursos técnicosactuales pueden ser mejorados o añadidos parasatisfacer la petición bajo consideración.

• A veces las “adiciones” a sistemas existentes puedenresultar costosas y no valen la pena.

• Si los sistemas existentes no pueden ser “añadido omejorados” el siguiente interrogante es:

Hay tecnología en existencia para satisfacer las

especificaciones?

• Si la respuesta a la Factibilidad Técnica es SI, entoncespasamos a la siguiente área la económica


42

Estudio

de

PrefactibilidadFactibilidad Económica• El negocio de que se trate deberá ser capaz de hacer

ver el valor de la inversión en su ponderación antesde comprometerse a un estudio de sistemascompleto.

• Si los costos a corto plazo no son sobrepasados porlas ganancias a largo plazo o no producen unareducción inmediata en los costos de operación

el sistema no es factible económicamente y elproyecto no debería continuar.

• Se realiza entonces una identificación y estimación deCostos y Beneficios.



22/25

43


Factibilidad

Económica ‐

Costos• Costo de construir el sistema: – Salarios y gastos extras del personal del equipo de proyecto. – Costo de preparación del personal de desarrollo. – Costo de tiempo de equipamiento utilizado. – Costo de reclutamiento de nuevo personal. – Costo de Viaje.

• Costo de instalar el sistema: Gastos de – Capacitación de usuarios – Conversión de bases de datos – Instalación comercial (hardware, software, telecomunic.)

– Aprobación reglamentaria – Ejecuciones paralelas – del equipo de desarrollo durante la instalación


44

Estudio

de

PrefactibilidadFactibilidad Económica ‐ Costos• Costo del dinero:

– Costo dinero a préstamo

– Beneficios que se habrían obtenido al invertirlo

• Costos operacionales: Costos de – Materiales y equipos relacionados (insumos).

– Software (si es rentado)

– Personal de operación , apoyo técnico, etc.

– Mantenimiento de hardware (preventivo, refacciones yreemplazos) y software (arreglos, mejoras)

– Planta física

• Costo del fracaso: Costo de posibles fallas.



23/25

45


Factibilidad

Económica ‐

Beneficios• Podemos clasificar los Beneficios de la siguientemanera:

– Beneficios Tangibles

– Beneficios Intangibles

Algunos los llaman también: Tácticos yEstratégicos.


46

Estudio

de

PrefactibilidadFactibilidad Económica ‐ Beneficios• Beneficios Tangibles: Son ventajas medibles en

pesos que se acumulan a la organización por el usodel sistema de información. – Reducciones de Personal – Mayor velocidad en el procesamiento de

transacciones – Reducción de costos de mantenimiento. – Acceso a información más oportuna. – Ventajas del poder superior de cálculo. – Disminución de tiempo de los empleados para

completar una tarea.

• Los beneficios tangibles se pueden medir entérmino de pesos, recursos o tiempo ahorrado.



24/25

47


Factibilidad

Económica ‐

Beneficios• Beneficios Intangibles: Algunos beneficios que seacumulan en la organización son difíciles de medir,muchas veces se refieren a la posibilidad de realizarcosas que no eran posibles con el sistema actual: – Mejora del proceso de toma de decisiones – Atraer nuevos clientes (mejor funcionalidad,

reconocimiento de potenciales clientes) – Entrar a nuevos mercados – Capturar, reproducir, distribuir conocimiento – Capacidad para proporcionar información que no se

tenía. – Incremento de la satisfacción en el trabajo por parte

de los empleados


48

Estudio

de

PrefactibilidadFactibilidad Operativa• La factibilidad operacional depende de los recursos

humanos disponibles para el proyecto e involucraproyectar si el sistema operará y será utilizado unavez que esté instalado.

– Aceptación del sistema por parte de los usuarios

– Capacitación necesaria para los usuarios.



25/25

49

Bibliografía

• Jacobson Ivar, Booch Grady, RumbaughJames, (2000), “El Proceso Unificado deDesarrollo de Software”, España, EditorialAddison Wesley.

• Kendall Kenneth y Kendall Julie, “Análisis yDiseño de Sistemas” (2005), 6ª. Ed. PrenticeHall Hispanoamericana.

• Pressman Roger, “Ingeniería del Sofware, un

enfoque práctico” (2006), 6ª . ed., Ed. McGraw Hill.


el proceso de software 2k7-2k10 - 2015 (1)

Documents