ing de sistemas 2 parte 2

INGENIERÍA DE SISTEMAS 2

Texto basado en el original de el Lic. Héctor Abel Contreras Hernández,

adaptado y parafraseado por Ing. Mario Alberto Caballero Vega.

Objetivos del tema:

Explicar las fases del ciclo de desarrollo de sistemas.

Identificar los roles y funciones de los diferentes actores en el desarrollo de un sistema

Categorizar los posibles riesgos del proceso de desarrollo de sistemas

Bloque 3: Desarrollo de aplicaciones

Los ciclos de la vida se conocen desde mucho tiempo atrás. Es así como se comenzó a medir el tiempo, se crearon los calendarios, y se comenzó a planear de acuerdo a las estaciones del año.

La vida misma de los seres humanos se dividió en etapas de acuerdo a los ciclos que se van cumpliendo a lo largo de la misma.

Este mismo concepto se ha aplicado en diferentes quehaceres del ser humano. La Tecnología Informática no podía ser la excepción y el desarrollo de sistemas de información en particular, ha adoptado de manera muy acertada este concepto.

Desarrollo de aplicaciones

Los pasos que se llevan a cabo para desarrollar un sistema no pueden considerarse como partes aisladas. Cada uno de estos pasos procede y alimenta al siguiente, ayudando a la evolución de lo que llegará a ser el sistema de información propiamente dicho.

3.1 Ciclo de vida del desarrollo de sistemasToda vez que se tiene en claro que las bases de un

sistema de información son las políticas y procedimientos de la organización en general, y de aquellas áreas que interactuarán en el proceso del sistema en particular.


Se requiere de una estrategia para atacar el problema que se nos plantea.

Ya estás ejerciendo tu nuevo puesto y ahora posees una visión bastante interesante de la organización en la que laboras, su estructura, sus políticas y sus procedimientos. ¿Cuál es el paso siguiente?

Muchos desarrolladores, líderes de proyecto y gerentes de sistemas se enfrentaron a este problema antes que tú y con la experiencia surgió un modelo de trabajo que se conoce como ciclo de vida del desarrollo de sistemas (SDLC por sus siglas en inglés).


Kendall y Kendall (2009) consideran siete las etapas que debiera contener el desarrollo de un sistema las cuales se mencionan como sigue:

1. Identificación de problemas, oportunidades y objetivos.

2. Determinación de los requerimientos de información.

3. Análisis de las necesidades del sistema.4. Diseño del sistema recomendado5. Desarrollo y documentación del software6. Pruebas y mantenimiento del sistema.7. Implementación y evaluación del sistema.


Pressman (2008) por otro lado, en Contreras (s/f) identifican el ciclo de vida como un tipo de desarrollo lineal que se compone de cinco etapas:

1. Planeación2. Análisis3. Diseño4. Implantación5. Mantenimiento


Otros autores, identifican únicamente cuatro etapas:

1. Análisis2. Diseño3. Implantación4. Mantenimiento

El ciclo de vida es la herramienta más antigua con la que se cuenta para desarrollar sistemas. A lo largo de este curso se trabajará con los elementos siguientes del ciclo de vida del desarrollo de un sistema.


Planeación:es la etapa más importante de cualquier proyecto. Es el primer acercamiento al tipo de desarrollo que se requiere, con qué elementos se contará,


Implantación y mantenimiento

Planeación

Recopilación de la información

Análisis de requerimientos

Diseño del sistema

Desarrollo del sistema

¿cuál será el alcance del proyecto?, ¿Cuál será la calendarización para el resto de las actividades?, ¿Cuáles son los recursos financieros y humanos?. Esto se realiza a nivel directivo.

Recopilación de información: toda vez que la planeación ha sido concluida, los procedimientos que se ven involucrados en este sistema de información deben ser recopilados en papel pero, más importante aún, a través de entrevistas y cuestionarios con los usuarios finales. Esta etapa es realizada a todos los niveles de la organización que se involucran directa o indirectamente con el sistema de información a desarrollar.


Análisis de requerimientos: mientras que la planeación nos brinda el panorama de lo que el nivel directivo requiere y la recopilación de datos nos muestra lo que se realiza día a día en la organización, el análisis de requerimientos nos permite juntar ambas percepciones y establecer los requerimientos reales del sistema de información de la organización.

Diseño del sistema: cuando los requerimientos han sido aprobados por los representantes de las áreas interesadas y participantes en el sistema de información, se comienza el diseño de lo que será el sistema. Se conceptualiza el funcionamiento que deberá tener, entradas, salidas, módulos, etc. Existiendo la posibilidad de realizar una representación o modelo de lo que será el sistema.


Desarrollo del sistema: El diseño del sistema de ser tan explícito que pueda ser programado sin depender de una plataforma de desarrollo en específico. Sin embargo, se espera que ciertas modificaciones técnicas tengan que aplicarse para que la plataforma de programación cumpla con los requerimientos planteados en el diseño. Aquí deben ser contemplados un número de programadores apropiado destinados a este proyecto.

En esta etapa es muy importante la interacción con el usuario final para ir depurando los posibles fallos en el sistema.


Implantación y mantenimiento: Toda vez que los representantes de la organización en general han aprobado la versión final del sistema éste se implantará de manera gradual liberando módulos. El mantenimiento deberá ser contemplado en este punto, aunque lo más importante en este sentido es tener la documentación, tanto en el código como en papel para garantizar un mantenimiento eficiente y una duración adecuada para cada sistema.


3.2 Funciones y responsabilidades Un supuesto importante de la

administración moderna es que la autoridad se delega y la responsabilidad se comparte.

Cada una de las etapas del desarrollo de sistemas tiene una serie de actividades que les corresponden uno o más responsables. Los responsables podrán variar de acuerdo a las características de cada organización.


La tabla siguiente servirá como referencia durante el desarrollo de tu proyecto:


Etapa Responsabilidades

Planeación Área directiva, administración de proyectos

Recopilación de información

Administración de proyectos, líder de proyectos, analistas.

Análisis de requerimientos

Administración de proyectos, líder de proyectos, analistas.

Diseño del sistema Líder de proyectos, analistas.

Desarrollo del sistema Líder de proyectos, analistas, programadores.

Implantación y mantenimiento

Líder de proyectos, analistas, programadores.

Es importante tener nombres de personas responsables y no sólo de las áreas en esta tabla.

Procura mantener juntas periódicas para informar al nivel directivo y operativo de los avances del proyecto.

Cada área o persona responsable de cada etapa, debe comprender sus responsabilidades y funciones de modo claro y específico.

Es importante recordar que las reuniones a nivel directivo deberán ser concreta y claras.


3.3 Riesgos en el desarrollo de sistemas

Cada proyecto de TI conlleva un riesgo inherente. Una mala planeación, una defectuosa recopilación de datos, un análisis de requerimientos mal aplicado o el diseño defectuoso del sistema de información; representan riesgos que pueden afectar los tiempos de entrega e incrementar el costo del sistema de modo considerable.

Cada una de las fases del desarrollo de sistemas, presenta un riesgo potencial si no es desarrollada de modo adecuado.


Entre los riesgos más importantes que se pueden encontrar se tienen:

• Factibilidad:el riesgo más elemental es que el costo-beneficio del sistema de información sea negativo. Cabe la posibilidad que al presentar el análisis del costo de nuestro sistema, el comité directivo decida no llevar a cabo el proyecto debido a que los beneficios no serán redituables comparados con el costo de producción del sistema.

• No terminar a tiempo el proyecto:La planeación fue defectuosa y no se puede terminar a tiempo el proyecto. Se requieren más recursos humanos, tecnológicos, financieros o de los tres tipos para concluir a tiempo el proyecto.


Cambios en los requerimientos: es necesario conforma a Contreras et al (s/f) delimitar el alcance del proyecto y las fechas límite para determinar el modelo final. Es posible que las áreas hagan solicitudes adicionales por contar con la posibilidad de un sistema de información que solucione sus problemas, comenzarán a añadir requerimientos al proyecto original sin contemplar la afectación que pueden causar en este sentido.


El sistema no cubre los requerimientos reales: pueden existir errores en el momento de definir los requerimientos del sistema de información o de identificar los procedimientos que se llevan a cabo. Sin importar el origen del error, si este problema no se corrige a tiempo puede generar fallas importantes dentro del sistema.

Resistencia al cambio: en la mayoría de las empresas, existe personal que tiene resistencia a nuevas tecnologías o nuevos procesos. Son estos elementos los que en ocasiones de manera consciente o inconsciente obstaculizan el desarrollo e implementación de un sistema de información.


Personal ineficiente: ya sea que se trate de un desarrollo interno o de una consultoría, es necesario elegir al personal adecuado para la realización del proyecto. La elección del personal que no cuente con la capacidad técnica, cognitiva y el compromiso adecuado para concluir de manera exitosa con el proyecto, puede provocar el fracaso.

Falta de apoyo al proyecto: Es importante mantener el interés de la alta dirección en el desarrollo del proyecto. Si no se cuenta con este apoyo explícito por parte de la dirección de la organización, se corre el riesgo de no permear al resto de la empresa con la importancia del proyecto.


En la tabla siguiente se puede apreciar algunos de los riesgos que se corren en cada fase del ciclo de vida del desarrollo de sistemas:


Etapa Riesgo

Planeación Factibilidad. No terminar a tiempo. Resistencia al cambio. Falta de apoyo al proyecto.

Recopilación de la información Cambios en los requerimientos

Análisis de requerimientos El sistema no cubre los requerimientos reales

Diseño del sistema El sistema no cubre los requerimientos reales. Personal ineficiente.

Desarrollo del sistema El sistema no cubre los requerimientos reales. Personal ineficiente.

Implantación y mantenimiento El sistema no cubre los requerimientos reales. Personal ineficiente.

Objetivos:• Utilizar las técnicas estructuradas del desarrollo

de sistemas.• Utilizar las técnicas tradicionales del desarrollo de

sistemas.

Bloque 4 Técnicas de desarrollo de sistemas

La importancia del desarrollo de sistemas en las organizaciones ha trascendido el ámbito tecnológico y financiero. Existen algunos que consideran al desarrollo de sistemas como un arte. En cualquier caso, el desarrollo de sistemas tiene un lugar especial en el área de la Tecnología Informática.

Este proceso requiere de la aplicación de una serie de técnicas que llevan a conseguir el resultado deseado de forma eficiente. Conocer y dominar estas técnicas facilita el éxito en el desarrollo de los sistemas de información.


Para practicar cualquier deporte, las primeras enseñanzas van enfocadas a la técnica del mismo. Es decir, lo primero que debemos aprender es la forma correcta en que se ejecuta algún movimiento

Que es parte básica del deporte que practicaremos. La única manera de dominar esa técnica es repitiéndola una y otra vez. Lo mismo ocurre en el desarrollo de sistemas.

Cuando nos involucramos en este tipo de proyectos en cualquier posición, es importante el aprendizaje que obtendremos en cada uno de los sistemas que pongamos en marcha.


La experiencia que pongamos en cada proyecto nos permitirá conocer y dominar las técnicas necesarias para optimizar los recursos que se nos ofrezcan al convertirnos en líderes de proyectos.


4.1 Técnicas tradicionales

La técnica de desarrollo de software tradicional o convencional fue la primera que surgió para satisfacer la necesidad de desarrollo de sistemas.

En realidad las técnicas tradicionales carecen de una metodología. El analista de sistemas, o su equivalente, proponía lo que mejor le parecía para la solución de un problema. Queriendo decir con esto que dentro de la organización surgía un problema a resolver y se solicitaba al ingeniero de sistemas que propusiera la mejor solución considerando como base la tecnología existente en el mercado, o en su defecto que generara un sistema de información que apoyara la solución de esta clase de problemas.


De esta manera el gurú de la informática, se las arreglaba para solucionar un problema en el área de producción que, dicho sea de paso, desconocía totalmente.

Los problemas principales al utilizar técnicas tradicionales son:

No existe manera de controlar lo que ocurre con el proyecto: este proyecto tiene un líder pero no una metodología. Los participantes en este proyecto, llámese programadores o analistas, dependerán del ingenio y proactividad del líder para sacar aadelante su trabajo. No existen puntos de medición.


El resultado es impredecible: como no existen análisis de requerimientos que integren a las áreas participantes, los resultados del sistema no pueden ser predichos ni medidos. No hay forma de definir si el sistema cumple o no con las necesidades identificadas en el problema.


No hay responsabilidad ni aceptación: las áreas involucradas en este tipo de proyecto no tienen responsabilidad alguna sobre este sistema de información ya que no fueron consultadas para su creación. En el mejor de los casos, el área de sistemas libera un producto que será adoptado por algunas áreas para su operación. La realidad es que en la mayoría de los casos, aún con el apoyo de la alta dirección, este tipo de sistemas terminan por morir ya que no responden a necesidades reales de la organización.


Cambios en la organización: en muchas ocasiones, estos sistemas han sido impulsados por la cúpula directiva de la organización sin tomar en cuenta a las áreas administrativas y operacionales de la empresa. Esto provoca que, ante un cambio de dirección dentro de la organización, el sistema termine por desaparecer o por no salir a la luz, provocando así un gasto inútil de tiempo, dinero y esfuerzo.

Los principales ejemplos en este sentido son las empresas o entidades gubernamentales a todos los niveles. Sin embargo, esto aplica en muchas ocasiones a las organizaciones privadas.


4.2 Técnicas estructuradas En la naturaleza todo tiene un orden. Inicio,

desarrollo y fin para decirlo de manera sencilla. Es decir, la naturaleza se encuentra estructurada y funciona así de forma adecuada.

Se conocen como técnicas o metodologías estructuradas, a aquellas con las características siguientes:

1. Tienen reglas predefinidas.2. Cubren el ciclo de vida del desarrollo de un

sistema.3. Pueden realizarse verificaciones en puntos

intermedios de un proceso.

Técnicas de desarrollo de sistemas

Pueden ser jerárquicas o no Están orientadas a datos Están orientadas a procesos Son mixtas (datos y procesos). Estas técnicas han evolucionado con el tiempo.

La siguiente tabla no brinda un idea cronológica de su evolución.


Año Técnica estructurada

1968 Conceptos de programación estructurada de DIJKSTRA

1975 Primeros conceptos sobre diseño estructurado MYERS y YOURDON

1978 Análisis estructurado: DEMARCO y WEINBERG

1985 Análisis y Diseño estructurado para sistemas de tiempo real. HATLEY y PIRHBAY

1989 METRICA

1990 SSADM

1995 METRICA versión 2.1


Las técnicas estructuradas se basan principalmente en el concepto de divide y vencerás. Es decir, aísla los componentes de un problema en partes pequeñas que puedan atacarse de un modo más sencillo y, después une las partes ya resueltas como si fuera un rompecabezas.

Más sin embargo, cabe señalar que si una pieza del rompecabezas se pierde o está mal hecha, afecta el resultado del desarrollo de sistemas. Son éstas técnicas las que ponen un énfasis muy especial a la documentación de los sistemas de información.


Los diagramas de flujo, Los diagramas de entidad relación, La documentación d e la definición de requerimientos, etc., son herramientas básicas que servirán posteriormente para dar mantenimiento o corregir el sistema diseñado.

La principal característica de una técnica estructurada comparándola a una tradicional es que las primeras son mejores herramientas para definir los requisitos reales del sistema. Además de poner mucho énfasis en la calidad del proyecto utilizando una metodología Top-down.


Según Pressman (s/f), las técnicas estructuradas pueden mostrarse como:

1. Análisis estructurado2. Diseño estructurado3. Desarrollo Top-Down4. Programación estructurada5. Revisiones estrucutradas


ing de sistemas 2 parte 2

Documents