Está en la página 1de 8

1.

Un sistema de información completamente formado pasa por


muchas etapas ejemplo planificación que es el proceso en que se
piensa como desarrollar el sistema hacer su estructura que puede ser
hasta ahora una simple idea de proyecto se realizan estudios como
cuál podría ser su competencia y que tecnología y calidad se usarían
y también se determina que recursos se necesitaran para la
construcción del software en esta etapa se debe mirar
detalladamente sus riesgos que se podrían presentar ya que si algo
grave falla se perdería su desarrollo se debe también tener claro los
requerimientos del cliente detallados y previamente estudiados en
esta etapa también es recomendable tomar nota o llevar apuntes de
lo bueno malo como se usaría y para que se usuaria es muy común
ver en la etapa de planificación desespero porque aún no se sabe
que camino coger para hacer un buen sistema así que es primordial
no desesperarse e ir desarrollando las dudas que se vayan
presentando por el camino .
Luego de esta etapa de construcción sigue otra importante como lo
es el análisis, en esta etapa se debe tener claro o determinar bien
saber para qué o que va a hacer el sistema, cuál será su
funcionalidad, descubrir qué es lo que realmente se necesita y se
llega a una comprensión adecuada de los requerimientos del sistema
(las características que el sistema debe poseer) Es importante saber
cuáles son en detalle los requerimientos del usuario Cuanto antes se
detecte un error, mejor. Distintos estudios han demostrado que
eliminar un error en las fases iniciales de un proyecto (en la etapa de
análisis) resulta de 10 a 100 veces más económico que subsanarlo
al final del proyecto. Conforme avanza el proyecto, el software se va
describiendo con un mayor nivel de detalle, se concreta cada vez más
y se convierte en algo cada vez más rígido. En la fase de análisis se
recopilan y analizan los datos acerca del sistema y su funcionamiento
aplicando cuestiones, entrevistas, encuestas, en general las técnicas
de recopilación de datos Especifica que es lo que el sistema debe
hacer.
También existen metodologías de análisis Las metodologías de análisis
particulares, de las que hay muchas, usualmente están ligadas, o
bien al uso de determinadas herramientas (por lo que el vendedor de
la herramienta se convierte, muchas veces, en el único promotor de
la metodología), o bien a empresas de consultoría concreta (que
ofrecen cursos de aprendizaje de la metodología que proponen). En
general, no obstante, la elección adecuada de las técnicas utilizadas
dependerá de la
situación concreta en la que se encuentre nuestro proyecto. Por este
motivo, lo más adecuado es aprender cuantas más técnicas mejor y
averiguar en qué situaciones resulta más efectiva
cada una de ellas.
La siguiente fase en la vida y construcción de software es el diseño
El propósito de esta fase es desarrollar un diseño (cómo va a quedar)
del sistema de información que satisfaga todos los requisitos
documentados. Se determina qué va a hacer el sistema. Se identifican
las entradas, salidas, archivos, programas, procedimientos y controles
del sistema. El documento creado se llama Especificaciones del Diseño
del Sistema y debe ser aprobado por la gerencia y los usuarios. Es
Determinar cómo funcionará de forma general sin entrar en detalles
incorporando consideraciones de la implementación tecnológica, como
el hardware, la red, etc. Consiste en el diseño de los componentes del
sistema que dan respuesta a las
funcionalidades descritas en la segunda etapa también conocidas como
las entidades de negocio. Generalmente se realiza en base a diagramas
que permitan describir las interacciones entre las entidades y su
secuenciado. La etapa del Diseño del Software encierra cuatro etapas:
Trasforma el modelo de dominio de la información, creado durante el
análisis, en las estructuras de datos necesarios para implementar el
Software. El diseño de los datos.: Define la relación entre cada uno de
los elementos estructurales del programa. El Diseño Arquitectónico.:
Describe como se comunica el Software consigo mismo, con los
sistemas que operan junto con él y con los operadores y usuarios que
lo emplean. El Diseño de la Interfaz. El Diseño de procedimientos.
El Diseño del software transforma elementos estructurales de la
arquitectura del programa. La importancia del Diseño del Software se
puede definir en una sola palabra Calidad, dentro del diseño es donde
se fomenta la calidad del Proyecto. El Diseño es la única manera de
materializar con precisión los requerimientos del cliente.
El proceso de Diseño es un conjunto de pasos repetitivos que permiten
al diseñador describir todos los aspectos del Sistema a construir. A lo
largo del diseño se evalúa la calidad del desarrollo del proyecto con un
conjunto de revisiones técnicas
La siguiente etapa implementación, Los programas son escritos,
probados y documentados. El propósito de esta fase es entregar un
sistema de información completo y documentado, que haya sido
revisado y aprobado por la gerencia y usuarios. Los preparativos
finales incluyen la conversión de datos, adiestramientos y la transición
del sistema viejo al nuevo. En esta fase se debe realizar una evaluación
del sistema luego de implantado para verificar costo-beneficio. El
resultado final de la fase de implantación es un sistema listo para
usarse. Es la fase más costosa y que consume más tiempo, se dice que
es costosa porque muchas personas, herramientas y recursos, están
involucrados en el proceso y consume mucho tiempo porque se
completa todo el trabajo realizado previamente durante el ciclo de vida.
En la fase de implementación se instala el nuevo sistema de información
para que empiece a trabajar y se capacita a sus usuarios para que
puedan utilizarlo. La instalación puede realizarse según cuatro
métodos: Directo, paralelo, piloto y en fases.
La siguiente fase pruebas niveles de pruebas con los tipos de prueba, y
a pesar de que se encuentren íntimamente relacionadas, tienen
connotaciones diferentes en el proceso. Para entender un poco más,
vamos a partir del hecho de que las pruebas pueden ejecutarse en
cualquier punto del proceso de desarrollo de software, y es aquí donde
los niveles de prueba nos permiten entender con claridad los diferentes
puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba.
Por lo anterior, es común que algunas personas se refieran a los niveles
de pruebas o intenten clasificarlos como: pruebas de desarrollador,
pruebas funcionales y pruebas de usuario final. Sin embargo, la
terminología apropiada para referirse a los diferentes niveles
corresponde a la siguientes cuatro (4) clasificaciones que son: pruebas
unitarias, pruebas de integración, pruebas de sistema y pruebas de
aceptación. En cada uno de estos niveles de prueba, se podrán ejecutar
diferentes tipos de prueba tales como: pruebas funcionales, no
funcionales, de arquitectura y asociadas el cambio de los productos.
La búsqueda de errores que se realiza en la etapa de pruebas puede
adaptar distintas formas,
en función del contexto y de la fase del proyecto en la que nos
encontremos:
- Las pruebas de unidad, Las pruebas de integración, pruebas alfa en el
seno de la
organización encargada del desarrollo del sistema. pruebas beta. test de
aceptación que, si se supera con éxito, marcará oficialmente el final del proceso
de desarrollo y el comienzo de la etapa de mantenimiento.
- Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer
revisiones de todos los productos generados a lo largo del proyecto, desde el
documento de especificación de requerimientos hasta el código de los distintos
módulos de una aplicación
La siguiente etapa instalación/despliegue De cara a su instalación, hemos de
planificar el entorno en el que el sistema debe funcionar, tanto hardware como
software: equipos necesarios y su configuración física, redes de interconexión
entre los equipos y de acceso a sistemas externos, sistemas operativos
(actualizados para evitar problemas de seguridad), bibliotecas y componentes
suministrados por terceras partes, etcétera. Para asegurar el correcto
funcionamiento del sistema, resulta esencial que tengamos en cuenta las
dependencias que pueden existir entre los distintos componentes del sistema y
sus versiones. Una aplicación puede que sólo funcione con una versión concreta
de una biblioteca auxiliar. Un disco duro puede que sólo rinda al nivel deseado
si instalamos un controlador concreto. Componentes que por separado
funcionarían correctamente, combinados causan problemas, por lo que
deberemos utilizar sólo combinaciones conocidas que no presenten problemas
de compatibilidad.
Uso y mantenimiento De cara a su instalación, hemos de planificar el entorno
en el que el sistema debe funcionar, tanto hardware como software: equipos
necesarios y su configuración física, redes de interconexión entre los equipos y
de acceso a sistemas externos, sistemas operativos (actualizados para evitar
problemas de seguridad), bibliotecas y componentes suministrados por terceras
partes, etcétera. Para asegurar el correcto funcionamiento del sistema, resulta
esencial que tengamos en cuenta las dependencias que pueden existir entre los
distintos componentes del sistema y sus versiones. Una aplicación puede que
sólo funcione con una versión concreta de una biblioteca auxiliar. Un disco duro
puede que sólo rinda al nivel deseado si instalamos un controlador concreto.
Componentes que por separado funcionarían correctamente, combinados
causan problemas, por lo que deberemos utilizar sólo combinaciones conocidas
que no presenten problemas de compatibilidad. es la modificación de un
producto de software después de la entrega, para corregir errores, mejorar el
rendimiento, u otros atributos.1 El mantenimiento del software es una de las
actividades más comunes en la ingeniería de software. El mantenimiento de
software es una actividad muy amplia que incluye la corrección de errores,
mejoras de las capacidades, eliminación de funciones obsoletas y optimización.
Debido a que el cambio es inevitable, se debe desarrollar mecanismos para la
evaluación, controlar y hacer modificaciones.
Ciclo de vida de una base de datos
Una base de datos no es más que un componente de un sistema de información.
Por tanto, el ciclo de vida del sistema de información incluye el ciclo de vida de
la base de datos que forma parte de él. En particular, desde el punto de vista de
la base de datos,
- Definición del sistema: Durante la etapa de análisis de requerimientos del
sistema, nos fijaremos especialmente en todos los requerimientos asociados a
los
datos con los que ha de trabajar nuestro sistema.
- Diseño de la base de datos: El análisis de los requerimientos del sistema nos
permitirá organizar los datos con los que nuestro sistema habrá de trabajar. Este
proceso de diseño, que está íntimamente ligado a la futura base de datos de
nuestro sistema, lo descompondremos en tres fases:
· diseño conceptual (descripción del esquema de la base de datos utilizando
un modelo de datos conceptual).
· diseño lógico (descripción de la base de datos con un modelo de datos
implementarle, como puede ser el caso del modelo relacional).
· Diseño físico (descripción de la base de datos a nivel interno, de acuerdo
con las características del sistema gestor de bases de datos que decidamos
utilizar).
- Implementación de la base de datos (la parte de la implementación del
sistema
correspondiente a la creación de la base de datos).
- Carga o conversión de los datos: Como parte de la instalación o despliegue
del
sistema, tendremos que introducir en la base de datos todos aquellos datos que
resulten necesarios para que las aplicaciones de nuestro sistema de información
puedan funcionar. Como parte de esta inicialización de la base de datos, puede
que resulte necesario extraer datos de otro sistema y convertirlos a un formato
adecuado para nuestro sistema (entre otras cosas, porque el esquema de
nuestra
base de datos probablemente diferirá del esquema de las bases de datos de las
que
se extraigan los datos necesarios para arrancar nuestro sistema).
- Conversión de aplicaciones: Si determinadas aplicaciones (que ya existiesen
anteriormente al diseño de nuestro sistema) han de seguir funcionando, dichas
aplicaciones deberán adaptarse al esquema de nuestra base de datos. Por tanto,
como parte del mantenimiento de dichas aplicaciones, tendremos que diseñar
los
mecanismos adecuados para que estas aplicaciones puedan seguir funcionando
Diseño consiste en diseñar la estructura lógica y física de una o más bases de
datos para atender las necesidades de información de los usuarios de un
conjunto definido de aplicaciones. Estos usuarios pueden pertenecer todos a una
organización concreta (como sucede con los trabajadores de una empresa o los
funcionarios de un organismo público), o bien formar parte de un colectivo con
intereses comunes (tal es el caso de los usuarios de multitud de aplicaciones
web, desde un buscador como Google hasta un servicio de información
geográfica tipo Páginas Amarillas).
la construcción de una base de datos se estructura en las siguientes fases.
- Análisis de requisitos
Es como se van a manejar los campos y cuantos campos exactamente deben ir
en la base de datos se esperan resultados como recolección de datos
transacciones y flujos de datos casos de uso
- Diseño conceptual
Producir un esquema conceptual de la base de datos (independiente del sistema
gestor de bases de datos que luego vayamos a utilizar).
Se esperan resultados como el modelo entidad relación y diagrama de clases
- Elección del sistema gestor de bases de datos
Un sistema gestor de bases de datos es un producto software con capacidad
para definir, mantener y utilizar bases de datos. El sistema de gestión de bases
de datos que decidamos utilizar debe permitirnos, entre otras cosas, definir
estructuras de almacenamiento adecuadas y acceder a los datos de forma
eficiente y segura. Se debe elegir por su buen manejo, no redundancia de datos
su fiabilidad organización y manejo de usuario
- Diseño lógico
Crear el esquema conceptual de la base de datos (y todos los esquemas
externos asociados a las distintas aplicaciones del sistema) de acuerdo con el
modelo de datos del sistema gestor de base de datos elegido se espera Un
conjunto de estructuras propias del modelo abstracto de datos del SGBD elegido
(esto es, un conjunto de tablas si trabajamos con bases de datos relacionales).
- Diseño físico
El diseño físico de la base de datos consiste en elegir las estructuras de
almacenamiento
apropiadas (tablas, particiones de tablas, índices...) para que el rendimiento de
la base de
datos sea el adecuado para las distintas aplicaciones a las que ha de dar
servicio. Se espera Un conjunto de sentencias DDL escritas en el lenguaje del
SGBD elegido (incluyendo la creación de índices, la selección de parámetros
físicos de la base de datos, etcétera).
- Instalación y mantenimiento
Como en cualquier sistema de información, casi siempre resulta necesario
modificar el diseño de la base de datos, ya sea porque el rendimiento observado
después de la implementación del sistema de bases de datos no sea el adecuado
o porque haya que introducir cambios en el esquema de la base de datos como
consecuencia del mantenimiento del sistema de información. Por ambos

Modelos de ciclo de vida


Antes de definir el modelo de ciclo de vida de desarrollo a seguir en una iteración
de un proyecto dentro de una empresa en el contexto colombiano, se debe
entender los fundamentos básicos, con pros y contras, de seguir un modelo
determinado. Esto incluye como primera medida, realizar un estudio de las
prácticas que se van a poner en ejecución dentro de un proyecto. Los modelos
híbridos (tradicionales y ágiles) deben ser estructurados teniendo en cuenta las
características propias del proyecto. Esto incluye las propias características del
contexto colombiano. Un modelo de ciclo de vida exitoso en un contexto, no
necesariamente lo es en otro contexto. Por ejemplo, ante el surgimiento de los
Parques Tecnológicos que incluyen empresas de desarrollo de software, se debe
tomar en cuenta las características propias del contexto de un grupo de jóvenes
emprendedores sin altos recursos para realizar inversión, con necesidad de
poner en el mercado en relativo poco tiempo un software altamente funcional de
excelente calidad. Un conjunto de preguntas que surgen ante la necesidad de
redefinir el modelo de desarrollo que un equipo sigue en un momento
determinado, con el fin de mejorar los resultados en términos de un conjunto de
atributos como pueden ser la calidad del software y la precisión de los planes
realizados, podrían ser las siguientes:
1. Cómo evaluar mi proceso de desarrollo?
2. Cómo identificar el conjunto de características que rodean mis desarrollos, e
impactan de manera significativa los resultados de mi equipo?
3. Cómo identificar el conjunto de prácticas adecuadas para incluir en un nuevo
modelo de ciclo de vida de desarrollo? La respuesta a estas preguntas se
enmarca en el tema de Mejoramiento de Procesos de Software, En este tema se
encuentra por ejemplo la propuesta realizada por el Instituto de Ingeniería de
Software con su
trabajo sobre IDEAL y CMMI. Sin embargo, al igual que para los procesos de
desarrollo, las prácticas requeridas para mejorar un proceso de software
dependen altamente del contexto donde se mejoran los procesos. Por ejemplo,
no es igual mejorar los procesos al interior de equipos con alta rotación, y gran
número de participantes, que mejorarlos en un equipo pequeño y estable. Para
el caso del contexto
colombiano, tomando como objetivo las pequeñas y medianas empresas, una
buena estrategia es evaluar los procesos frente a un marco de referencia como
puede ser CMMI en cada una de sus áreas de proceso. Luego de tener una
evaluación inicial del estado actual de los procesos, y definir lo que se puede
llamar una línea base de procesos, se debe realizar un plan de mejoramiento
basado en las características del equipo de desarrollo. Un buen ejercicio para
identificar estas características es realizar un árbol de problemas como el
presentado en la figura 1. Por medio de este tipo de esquemas, se pueden
identificar características que de alguna manera no se tomaban en cuenta.
Finalmente, para identificar las prácticas precisas que se deben incluir en el
nuevo modelo de desarrollo, se debe tener en cuenta el marco de referencia con
el cual se evaluó el proceso actual, y las características identificadas. Así, de
manera incremental, se incorporan prácticas en un orden que se defina como
prioritario al interior del equipo para minimizar los impactos negativos de
características del equipo identificadas, en los
proyectos de desarrollo. Algo que siempre se debe tener en cuenta es la
definición de métricas desde el inicio de mejoramiento, que permitan medir la
mejora una vez los procesos. A estas métricas se les conoce como indicadores
de gestión del mejoramiento de procesos.

2. //Ciclo de vida Lineal


Planificación
Este proceso se llevó a cabo en el mes de septiembre del año 2017 en el cual se
realizaron entrevistas al cliente para saber cuál era el problema a solucionar, para así
empezar con la recolección de los requerimiento funcionales y no funcionales para el
sistema a desarrollar además con esto se planeó muy detalladamente el tiempo y los
recursos a utilizar.
Análisis
Esta fase se llevó a cabo en los meses de noviembre y diciembre del 2017, donde se
obtuvieron todos los requerimientos y se llevaron a cabo reuniones con el cliente para
poder realizar un mejor análisis de los requerimientos antes obtenidos, de esta manera
el cliente es más específico con las necesidades que debe cumplir el sistema de
información.
Diseño La fase de diseño se realiza actualmente, en donde se planifica la interacción
de los módulos, las interfaces que estos tendrán y la interacción que tienen con la base
de datos, pensando siempre en la necesidad del cliente para mejorar los procesos que
se realizan actualmente

3./// para el curso que estamos desarrollando ADSI aplica el ciclo en cascada,
ya que se comprueba que el sistema se divide en varios subsistemas
independientes entre sí, sería razonable suponer que a partir de ese punto
cada uno se puede desarrollar por separado y en consecuencia en paralelo con
los demás. Cada uno tendrá seguramente fechas de terminación distintas. Una
vez que han terminado todos se integran y se prueba el sistema en su
conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo
de forma eficiente. El riesgo es que existan interdependencias entre los sub
proyectos.

** Requiere planeación.

** Plantea Organización y planeación de un gran proyecto Se pueden realizar


varias partes del proyecto al mismo tiempo por diferentes desarrolladores

**Adecuada para el desarrollo de proyectos complejos que estiman de 1 a 3


años de desarrollo

También podría gustarte