1. Metodologías de diseño y desarrollo de sistemas de
información
República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
Instituto Universitario Politécnico “Santiago Mariño”
Barcelona – Edo. Anzoátegui
Bachiller:
Danianny Hurtado C.I:
24,392,194
Profesora:
Amelia Vásquez
2. La necesidad de administrar es una distinción importante entre un desarrollo profesional
de software y la programación no profesional. La administración de proyectos de software es
necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones
de presupuesto y calendarización; a las que debe ajustarse la organización que desarrolla el
software. El trabajo del administrador de proyectos de software es asegurar que éstos cumplan
dichas restricciones y entregar software que contribuya a las metas del negocio. Una buena
administración no garantiza el éxito del proyecto, sin embrago la mala siempre asegura el
fracaso del mismo.
Debido a estos problemas, no es sorprendente que algunos proyectos de software se
retrasen, sobrepasen el presupuesto y estén fuera de tiempo. A menudo los sistemas de
software son nuevos y tecnológicamente innovadores. Frecuentemente los proyectos de
ingeniería innovadores también tienen problemas de calendarización.
Por todo esto es necesario conocer los distintos términos, factores y metodologías
utilizadas para la eficacia y eficiencia del proyecto de software que se plantea.
3. Un proyecto de software es el Proceso de gestión para la creación de un Sistema o
software, la cual encierra un conjunto de actividades, una de las cuales es la estimación,
estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.
El objetivo de la Planificación del proyecto de Software es proporcionar un marco de
trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación
temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de
un proyecto de software, y deberían actualizarse regularmente medida que progresa el
proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso,
de modo que los resultados del proyecto pueden limitarse.
4. Actividades asociadas al proyecto de software:
Ámbito del Software: En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software
para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos.
Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del
ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación.
Recursos: es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto
esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la
infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los
Componentes reutilizables.
Estimación del Proyecto de Software: Un gran error en la estimación del costo puede ser lo que marque la
diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia
exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final
del software y el esfuerzo aplicado para desarrollarlo.
5. Es importante planificar porque se evitan o aminoran riesgos innecesarios. Al hacerlo, es
necesario determinar y prever los posibles elementos adversos al plan y cómo éste puede
verse afectado por dichos elementos.
Sin planificación, los proyectos y organizaciones marcharían a la deriva. Por ello, hay que
considerar una serie de factores vinculados a este proceso, como disipar el mayor número de
incertidumbres con respecto al proyecto o determinar con bastante aproximación las
necesidades de recursos y los fondos a requerir para cumplir los objetivos establecidos.
Es una tarea fundamental en la ingeniería, ya que planificar, efectuar y evaluar los estudios
de factibilidad inherentes a todo proyecto de diseño de sistemas de información y de
modificación o reemplazo de los mismos, son aspectos que deben considerarse en cada
momento.
Para así asegurar en todo lo posible que el proyecto sea exitoso y reducir en gran medida
los riesgos que se puedan presentar a lo largo del trayecto.
6. El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño
que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo
especifico de actividades del analista y del usuario.
Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida.
Su ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:
Planificación: Realizar una serie de tareas previas que influirán decisivamente en la finalización con éxito del proyecto.
Análisis: Averiguar qué es exactamente lo que tiene que hacer el sistema.
Diseño: Diseño arquitectónico del sistema.
Implementación: Seleccionar las herramientas adecuadas, un entorno de desarrollo y un lenguaje de programación apropiado.
Pruebas: Tiene como objetivo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto.
Instalación: Debemos de planificar el entorno en el que el sistema debe funcionar, tanto hardware como software.
Uso y Mantenimiento: Elimina defectos, adapta a nuevas necesidades y añade nuevas funciones.
7. Ciclo de Vida Clásico: El modelo de ciclo de vida
clásico, también denominado “modelo en cascada”, se
basa en intentar hacer las cosas bien desde el principio,
de una vez y para siempre. Se pasa, en orden, de una
etapa a la siguiente sólo tras finalizar con éxito las
tareas de verificación y validación propias de la etapa.
Si resulta necesario, únicamente se da marcha atrás
hasta la fase inmediatamente anterior.
Este modelo tradicional de ciclo de vida exige una
aproximación secuencial al proceso de desarrollo del
software.
8. Desarrollo de Prototipos: Normalmente, el
cliente es capaz de definir un conjunto general de
objetivos para el sistema que hemos de construir, pero
no identifica los requisitos detallados. En otros casos,
puede que nosotros no estemos seguros de la
eficiencia de un algoritmo, de la capacidad de nuestro
diseño para soportar los requerimientos del sistema o
de la forma en que debe diseñarse la interfaz de
usuario. En cualquiera de estas situaciones, resulta
adecuado construir un prototipo.
El desarrollo de prototipos reduce el riesgo de que
nuestro proyecto fracase y facilita la especificación de
requerimientos de productos que desconocemos. Sin
embargo, también tiene sus inconvenientes: el cliente
puede pensar que el prototipo es el sistema definitivo,
ignorando que un prototipo no es un sistema acabado
aunque tenga el mismo aspecto externo.
9. Modelo en Espiral de Barry Boehm: Hace especial hincapié en la prevención de riesgos. Este
modelo define cuatro actividades principales: planificación (determinar los objetivos, alternativas y
restricciones del proyecto), análisis de riesgos (análisis de alternativas e identificación/resolución de
riesgos), ingeniería (desarrollo del producto) y evaluación (revisión por parte del cliente y valoración de
los resultados obtenidos de cara a la siguiente iteración). En cada iteración alrededor de la espiral se
construyen versiones cada vez más completas del software.
10. Metodología del Proceso Unificado de Desarrollo (RUP): traza pautas muy concretas para el
desarrollo de proyecto de software, define en un enfoque de alta colaboración, evolutivo y flexible para
asimilar los cambios en los requerimientos del software en un ambiente de negocios dinámico. De igual
forma define claramente los hitos donde son necesarias la revisiones formales del proyecto, las cuales
incluyen la aprobación por parte del cliente. Diagrama del ciclo de vida de un proyecto de
software basado en RUP:
11. Cualquier sistema de información va pasando por una serie de fases a lo largo de su
vida. Su ciclo de vida comprende una serie de etapas entre las que se encuentran las
siguientes:
A esta fase también se le
llama de Diagnostico, en
esta fase se perciben las
necesidades y objetivos de
la organización.
Se elaboran las
especificaciones detalladas
del sistema, se determinan
los datos necesarios, su
formato, la capacidad del
equipo, etc.
Implica principalmente la
programación de los
equipos de computo: la
prueba de los programas y
la elaboración de la
documentación respectiva.
Implica la preparación del
sistema, así como todas las
pruebas reales y en
paralelo al proyecto.
12. La finalidad es obtener la Documentación de la Especificación de las
historias de usuario y Definir las responsabilidades del equipo de
desarrollo para las pruebas de recepción del Sistema. Para conseguir un
entendimiento común entre el cliente y el proyecto. Se compone por uno
o más ciclos de desarrollo.
La estimaciones razonables de recursos, costos y planificación
temporal se hacen dentro de un marco de tiempo limitado al comienzo
de un proyecto de software, y deberían actualizarse regularmente a
medida que progresa el proyecto.
Las estimaciones deberían definir los escenario del mejor caso, y
peor caso de modo que los resultados del proyecto pueden limitarse.
13. Cuando se planea un proyecto de software ese tiene que obtener estimaciones de esfuerzo humano requerido, de
la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de
la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto pasado es
probable que el nuevo requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo
que el trabajo anterior. Se puede trabajar con las herramientas:
Diagrama de Gantt: Herramienta gráfica
que muestra el tiempo de dedicación
previsto para diferentes tareas o actividades
a lo largo de un tiempo total determinado,
en principio, no indica las relaciones
existentes entre actividades, la posición de
cada tarea a lo largo del tiempo hace que
se puedan identificar dichas relaciones e
interdependencias.
Método Pert: Se utiliza en todo método
espacial. Busca el control y la optimización de los
costos de operación mediante la planeación
adecuada de las actividades componentes del
proyecto. Aporta elementos administrativos
necesarios para formar el método del camino
crítico actual, utilizando el control de los tiempos
de ejecución y los costos de operación, para
buscar que el proyecto total sea ejecutado en el
menor tiempo y al menor costo posible.
14. Después de definir la problemática del proyecto y establecer las causas que ameritan de un nuevo
sistema, es pertinente realizar un estudio de factibilidad para determinar la infraestructura tecnológica y la
capacidad técnica que implica la implantación del sistema en cuestión, así como los costos, beneficios y el
grado de aceptación que la propuesta genera en la organización.
Factibilidad Operativa: Permite
predecir si se pondrá en marcha el
sistema propuesto, aprovechando
los beneficios que ofrece a todos los
usuarios involucrados con el mismo,
ya sean los que interactúan en forma
directa con este, como también
aquellos que reciben información
producida por el sistema.
Factibilidad Técnica: Consiste en
realizar una evaluación de la tecnología
existente en la organización, se recolecta
información sobre los componentes
técnicos que posee la organización y la
posibilidad de hacer uso de los mismos
y de ser necesario, los requerimientos
tecnológicos que deben ser adquiridos
para el desarrollo del sistema.
15. Este análisis permite determinar las posibilidades de diseñar el sistema propuesto y su puesta en
marcha, los aspectos que se toman en cuenta para este estudio son generalmente clasificados en cuatro
áreas: operativa, económica, técnica y legal.
Factibilidad Económica: En esta
etapa, hay que comprobar que el
proyecto es sustentable
económicamente Justificar que la
inversión genera una ganancia,
demostrar que si el sistema no
cumple con su objetivo no
habrán perdidas económicas o
serán las mínimas.
Factibilidad Legal: Establece los
requerimientos legales del proyecto
para su operación y aprobación, las
licencias para el software a
emplearse en la implantación del
sistema informático de información
con la finalidad de no tener
inconvenientes legales a futuro y los
contratos de servicios.
16. El desarrollo de software es uno de los pilares fundamentales de la Informática y al cual se
dedican muchas horas de esfuerzos en universidades, centros de investigación y empresas de
todos los tamaños.
Conforme la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de
programación, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo
del desarrollador un poco mas fácil. También surgen nuevos modelos de proceso de
desarrollo y nuevas metodologías que tratan de adaptar la manera de trabajar a las
necesidades concretas de una organización y de sus proyectos. Es importante conocer bien
estos modelos, para tener un esquema mental que nos permita gestionar proyectos y
organizar equipos de manera racional, cuando abordemos el desarrollo de software,
especialmente en el caso de aplicaciones grandes y complejas.
17. Cervantes Alejandro: Ciclo de vida de un sistema de información. Julio de 2015 de
https://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/.
Conexión ESAN: La importancia de la planificación en los proyectos. Mayo de 2013 de
https://www.esan.edu.pe/conexion/actualidad/2013/05/30/importancia-planificacion-proyectos/.
González Carlos: Planeación y calendarización en proyectos de software. Julio de 2009 de
https://www.gestiopolis.com/planeacion-calendarizacion-proyectos-software/.
Ingeniería de sistemas de Información. (s.f.). En Wikipedia. Recuperado el 29 de marzo de 2018 de
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_sistemas_de_informaci%C3%B3n.
Medina María: Ingeniería del Software. Noviembre de 2012 de
http://isittla12.blogspot.com/2012/11/unidad-3planificacion-del-proyecto-de.html.
Rivas Abdel: Estudio de Factibilidad de un Sistema. Enero de 2013 de
http://mundoinformatico321.blogspot.com/2013/01/estudio-de-factibilidad-de-un-sistema.html.