Está en la página 1de 11

CONTENIDO

II. PROCESO DE DESARROLLO DE SOFTWARE. ................................................. 2


III. ÁREAS DE PROBLEMAS .............................................................................. 4
IV. CAUSAS DE ÉXITO Y FRACASO ................................................................... 5
V. ADMINISTRACIÓN DE LA IMPLANTACIÓN. ................................................... 6
VI. ANÁLISIS .................................................................................................... 8
VII. PRINCIPIOS ................................................................................................ 8
VIII. REVISIÓN DE LA ESPECIFICACIÓN .............................................................. 8
IX. DIAGRAMAS DE CONTEXTO DFD Y E/R ..................................................... 9
X. MODELADOS DE COMPORTAMIENTO.......................................................... 9
XI. FLUJO DE PROCESOS. .............................................................................. 10

1
I. PROCESO DE DESARROLLO DE SOFTWARE.
Software tiene como propósito la producción eficaz y eficiente de un producto software
que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la
Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad y juicio
de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es
equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo
de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza
del producto obtenido. A continuación se explican algunas particularidades asociadas al
desarrollo de software y que influyen en su proceso de construcción.

Requisitos nuevos Sistema nuevo


o modificados o modificado
Proceso de Desarrollo
de Software

En este proceso se determina qué tipo de desarrollo de software interesa. Existen dos
tipos básicos de desarrollo de software: “El de aplicaciones” y “El de sistemas”.

2
El desarrollo de aplicaciones se enfoca en crear programas que cumplen con las
necesidades del usuario. Estas aplicaciones van desde aplicaciones para celular o video
juegos, hasta software de contabilidad a nivel empresarial.

El desarrollo de sistemas se enfoca en crear y mantener sistemas operativos usando


desarrollo de ciclo de vida. El desarrollo de sistemas a menudo involucra operatividad de
red y seguridad de información.

Un proceso de desarrollo de software es la descripción de una secuencia de actividades que


deben ser seguidas por un equipo de trabajadores para generar un conjunto coherente de
productos, uno de los cuales en el programa del sistema deseado.

El desarrollo de un software no es más que Crear e Implantar un sistema software, por


ejemplo, Software de tipo aplicación que automatice el trabajo en una organización.

3
II. ÁREAS DE PROBLEMAS

Los problemas que ocasionan la falla total de los sistemas de información caen en
diferentes categorías como se ilustra en la siguiente imagen.

DISEÑO El diseño real del sistema falla al no captar los requerimientos esenciales del
negocio. La información puede no ser proporcionada lo suficientemente rápido para ser
útil; puede venir en un formato imposible de digerir y usar, o puede representar los
elementos equivocados de datos. La manera en la cual usuarios no técnicos de negocios
deben interactuar con el sistema puede ser excesivamente complicada y descorazonadora.
Un sistema de información será juzgado como un fracaso si su diseño no es compatible con
la estructura, cultura y metas de la institución.

DATOS Los datos en el sistema tienen un alto grado de imprecisión o de inconsistencia. La


información en ciertos campos puede ser errónea o ambigua: puede no ser fragmentada
adecuadamente para fines de negocios. La información que se requiere para una función
específica de negocios puede ser inaccesible porque los datos están incompletos.

4
COSTOS Algunos sistemas operan muy suavemente (es decir influyen poco en
la organización), pero el costo para implementarlos y operarlos en su fase de producción
queda muy por encima del presupuesto. Estos gastos excesivos no pueden justificarse por el
valor de negocios demostrado para la institución de la información que proporcionan.

OPERACIONES El sistema no opera bien. La información no se proporciona de


manera oportuna y eficiente porque las operaciones de computadora que manejan el
procesamiento de la información se caen. Las operaciones que abortan con mucha
frecuencia conducen a reproceso excesivos y programas con retrasos o no cumplidos para
la entrega de la información.

III. CAUSAS DE ÉXITO Y FRACASO

Se ha encontrado que el resultado de la implantación puede quedar determinado por los


siguientes factores:

El papel de los usuarios en el proceso de implantación.


El grado de apoyo directivo para el esfuerzo de la implantación.
El nivel de riesgo y complejidad del proyecto de implantación.
La calidad del proceso de implantación.

A continuación se presentan algunas de las razones del porque una empresa consigue
el éxito al implementar cualquier de estos tipos de software o porque una empresa fracasa
a pesar de contar con uno de estos.

De acuerdo con las compañías como NIKE, DHL, Tektronix, Fujitsu, Millipore, Sun
Microsystems, algunas de las razones por la que tuvieron éxito al implementar un tipo
software (ERP, CRM, SAP, FS, etc.) son:

 Tuvieron más control para el personal que manejaba las cuentas por pagar,
facturación, por lo que aumentaros su productividad y eliminaron la necesidad de
personal para la operación en las computadoras.

 Mayor rapidez al entrar al sistema y recobrar información en vez de buscar esa


documentación en archivos de papel. Reducción de tiempo.

 La nueva información que ocurre día a día se captura al momento de la operación y


no se tienen que esperar cada dos semanas o cada mes para capturarla.

 La información es más precisa con la cual los auditores quedan satisfechos.

 Los sistemas han ayudado para el control de los costos.

5
 Se tiene una rápida respuesta y seguimiento de los clientes.

 Se monitorea de una manera más eficaz para consultar cualquier tipo de


información.

Algunas de las razones por las cuales las empresas fracasan al implementar este
tipo de software son las siguientes:

 Piensan que al implementar este tipo de tecnología, va a resolver todos los aspectos
de la empresa por si sola y no es así pues muchas veces este tipo de software no es
la solución para lo que la empresa requiere es decir no se tienen bien definidos los
objetivos del negocio.

 No existe en la organización pasión por aprender nuevas formas de operar.

 No se tiene una estrategia definida y no existe una correcta asignación de recursos


y no hay una correcta metodología para el desarrollo del proyecto.

 No se redefinen los procesos del negocio para conseguir los resultados deseados.

 No se tienen datos o información de calidad, pues en muchos de los casos los datos
e información de clientes es básica pues de ella se pueden extraer conclusiones.

 No se gestiona correctamente el cambio.

 No se cuenta con una parte analítica y sin esta se pierden muchas de las ventajas
que estos sistemas ofrecen.

Otras razones de fracaso también podrían ser causas relacionadas con la inmadurez del
mercado: soluciones poco evolucionadas y validadas, falta de soluciones “verticales”, falta
de consultores especializados, etc. Pero en sí, los motivos por los cuales fracasan este tipo
de proyectos es por el cambio organizacional, las prácticas en la empresa, la falta de
entendimiento al sistema, la mala planificación, los fallos en el manejo, los problemas
presupuestarios entre otros, etc.

IV. ADMINISTRACIÓN DE LA IMPLANTACIÓN.

El proceso de implantación constituye el último eslabón de la metodología de desarrollo de


implantación del software y es posterior al proceso de prueba (ver Proceso de Prueba). A
pesar de todo el trabajo requerido para llegar a este punto, la fase de implantación puede
ser la más difícil.

6
Como con los procesos de desarrollo y prueba, la complejidad depende de las características
de la tecnología. Si se trata de un producto estándar, la implantación puede ser
relativamente fácil. Los usuarios también pueden estar relativamente familiarizados con
ella si no difiere sustancialmente de la que se utilizaba con anterioridad.

Sin embargo, cuando se trata de una nueva tecnología, que no ha sido aplicada con
anterioridad o difiere sustancialmente de las prácticas previas, el proceso de implantación
debe ser manejado con extremo cuidado y mucha atención en los detalles.

Contar con el equipo de personas adecuado resultará definitivo. A partir de este punto y
hasta completar la implantación de algún tipo de software se deberá conformar un equipo
de trabajo altamente calificado que le permita llevar a cabo las definiciones críticas del
proyecto, tales como cuáles módulos habrán de implantarse, los ajustes o modificaciones
que requieren y el orden en que deberán ser implantados. Este grupo de trabajo,
generalmente conformado por gerentes de diferentes departamentos, deberá involucrase
plenamente con el sistema hasta llegar a conocer los detalles de su funcionamiento.

7
V. ANÁLISIS
En esta fase se analizan las necesidades de los usuarios finales del software para determinar
qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de
especificación de requisitos), que contiene la especificación completa de lo que debe hacer
el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir
nuevos resultados a mitad del proceso de elaboración del software de una manera.

VI. PRINCIPIOS

El modelo de cascada define las siguientes etapas que deben cumplirse de


forma sucesiva:
1. Especificación de requisitos.
2. Diseño del software.
3. Construcción o Implementación del software.
4. Integración.
5. Pruebas (o validación)
6. Despliegue (o instalación)
7. Mantenimiento.

VII. REVISIÓN DE LA ESPECIFICACIÓN


El objetivo principal de la Especificación de Requisitos del Sistema (ERS) es servir
como medio de comunicación entre clientes, usuarios, ingenieros de requisitos y
desarrolladores. En la ERS deben recogerse tanto las necesidades de clientes y usuarios
(necesidades del negocio, también conocidas como requisitos de usuario, requisitos de
cliente, necesidades de usuario, etc.) como los requisitos que debe cumplir el sistema
software a desarrollar para satisfacer dichas necesidades (requisitos del producto, también
conocidos como requisitos de sistema o requisitos software).
La ERS debe ser un documento consensuado entre todas las partes y tener un carácter
contractual, de forma que cualquier cambio que se desee realizar en él una vez acordada la
primera línea base deba aplicarse siguiendo el Procedimiento de Control de Cambios
establecido en el proyecto.

8
VIII. DIAGRAMAS DE CONTEXTO DFD Y E/R

Un diagrama de flujo de datos (DFD) traza el flujo de la información para cualquier proceso
o sistema. Emplea símbolos definidos, como rectángulos, círculos y flechas, además de
etiquetas de texto breves, para mostrar las entradas y salidas de datos, los puntos de
almacenamiento y las rutas entre cada destino.

IX. MODELADOS DE COMPORTAMIENTO

El modelo de comportamiento es parte del Modelo Esencial, junto con el modelo


ambiental. Se desarrolla en el proceso o momento de análisis (análisis estructurado) de un
sistema.

El modelo de comportamiento es el conjunto de modelos (esquemas, diagramas) de un


sistema, ese conjunto de modelos puede incluir:

- DFD (diagrama de flujo de datos): cómo son procesados los datos en el sistema.
- DTE (diagrama de estados): cómo el sistema se comporta frente a eventos.
- DER (diagrama entidad-relación)
- DD (diccionario de datos)
- EP (especificación de procesos)

Estos modelos de comportamiento son empleados para describir cómo funcionará el


sistema que se desarrollará.

9
En ocasiones sólo un modelo de flujo de datos puede ser necesario para representar cómo
se comporta el sistema, especialmente en los sistemas de negocio.

En tanto en los sistemas de tiempo real es más útil para representar su comportamiento el
diagrama de estados (o modelo de máquina de estados).

También existen otros sistemas que pueden estar dirigidos tanto por datos como por
eventos y, en estos casos, se suelen representar ambos tipos de modelos.

X. FLUJO DE PROCESOS.

Un diagrama de flujo es una representación gráfica de un proceso. Cada paso del proceso
se representa por un símbolo flujo diferente que contiene una breve descripción de la
etapa de proceso. Los símbolos gráficos del flujo del proceso están unidos entre sí con
flechas que indican la dirección de flujo del proceso.

El diagrama de flujo ofrece una descripción visual de las actividades implicadas en un


proceso. Muestra la relación secuencial entre ellas, facilitando la rápida comprensión de
cada actividad y su relación con las demás, el flujo de la información y los materiales, las
ramas en el proceso, la existencia de bucles repetitivos, el número de pasos del proceso,
las operaciones de interdepartamentales… Facilita también la selección de indicadores de
proceso.

10
En primer lugar, facilita la obtención de una visión transparente del proceso, mejorando
su comprensión. El conjunto de actividades, relaciones e incidencias de un proceso no es
fácilmente discernible a priori. La diagramación hace posible aprehender ese conjunto e ir
más allá, centrándose en aspectos específicos del mismo, apreciando las interrelaciones
que forman parte del proceso así como las que se dan con otros procesos y subprocesos.

Permite definir los límites de un proceso. A veces estos límites no son tan evidentes, no
estando definidos los distintos proveedores y clientes (internos y externos) involucrados.
El diagrama de flujo facilita la identificación de los clientes. Es más sencillo determinar sus
necesidades y ajustar el proceso hacia la satisfacción de sus necesidades y expectativas.
Estimula el pensamiento analítico en el momento de estudiar un proceso, haciendo más
factible generar alternativas útiles.

11

También podría gustarte