FANDOM


Bienvenidos a Ingenieria de requerimientos Wiki
El wiki sobre (añade aquí el tema) que todos pueden editar. 1 artículos desde (Mes) (Año)

Actividad reciente

Colabora con este wiki

Para escribir un artículo, ingresa el título en la caja de abajo.

¿No estás seguro por dónde comenzar?

Las imágenes y videos son una gran manera de atraer lectores a tu wiki. ¡No olvides colocar uno u otro!

Fareandina


CONTENIDO

1.      Introducción

2.      Objetivos

3.      Planteamiento del problema

·         Propósito

·         Alcance del proyecto

4.      Especificación de requerimientos.

·         Lista de Chequeo

5.      Método de la investigación

6.      Metodología adecuada para el desarrollo del proyecto.

·         Metodología de la investigación

7.      FASES DE PROYECTO

·         Análisis de Requisitos

·         Diseño y arquitectura

·         Esquema

·         Programación

·         Pruebas

·         Documentación

·         mantenimiento

8.      Cómo Asegurar La Calidad Del Producto

·         Planificación

·         Evaluación

·         Comunicación

9.      Conclusión

10.  Referencias

1.      INTRODUCCION

Los sistemas de información se basan en sistemas lógicos que están diseñados para tratar de ser universales. Esa universalidad hace que el proceso deba cumplir con características de desarrollo que, aunque estén escritas en muchos lenguajes sirva para que cualquier persona esté en condiciones de entender dichos sistemas. Cuando una organización tiene la intención de adquirir un sistema, aplicación, o desarrollo de información y desea integrarlo a sus  su sistema de negocio cada vez más complejos , esto  obliga a buscar nuevas soluciones, nuevos caminos o nuevos sistemas de desarrollo  solucionen dichos requerimientos , La solución generalmente incluye un software el cual necesitara integrar muchas horas de trabajo , por la gran cantidad de información y dependiendo la complejidad de la solución a presentar . Por esto  el desarrollo del Software se ha convertido en una tarea muy compleja por la cantidad de requerimientos que hoy en día piden los clientes , y todo esto debido a los tiempos en que vivimos ya que por lo regular se solicita aplicaciones que puedan gestionarse desde internet ,con gran cantidad de data asociando API¨S con diferentes plataformas para que todas puedan hablarse esto hace  que ha haya  sobrepasado en gran medida la habilidad para el mantenimiento de las empresas que se dedican al desarrollo de software. Hoy en día, las empresas buscan una alternativa para mejorar la producción por ende las empresas desarrolladoras deben invertir en nuevas tecnologías de desarrollo de software, que garantice la calidad y la satisfacción al cliente final.

En estos tiempos no  es tan sencillo comprender los objetivos  que  abarca cualquier  proyecto, por ende se debe realizar bien los procesos de levantamiento de información para que pueda el producto final cumplir  su misión para la cual fue desarrollado  De este modo, el presente proyecto  trata  de   proporcionar  un sistema que ayude con  proceso que se requiere con calidad,  basado  en  un  equipamiento  nuevas  tecnologías y desarrollo de garantía.

2.      OBJETIVOS

·         Comprender y Describir los conceptos relacionados con la ingeniería y administración de requerimientos protocolos y sistemas que se utilizan para entender los procesos que se realizan antes de desarrollar cualquier software

·         Comprender que la ingeniería de proyectos a es diseñar, implementar, implantar, y hacer uso de sistemas de información para dotar de alguna forma seguridad, estabilidad y un servicio confiable en el desarrollo de un sistema de software.

·         Comprender y analizar los procesos que se necesitan para garantizar que la información de los procesos suministrados pueda estar de manera segura a través de compromisos de confidencialidad. Para conseguirlo desarrollar técnicas de recolección de información verídicas y confiables.

·         Determinar Integridad. y garantizar la corrección y completitud de la información. Para conseguirlo y poder desarrollar funciones, protocolos de compromiso

·         Comprender las necesidades de los clientes con la información que se recoge y tener claridad en los procesos que se necesitan para implementar una solución de desarrollo de aplicaciones.

3.      Planteamiento del problema

La universidad cuenta con una flota de vehículos para el transporte de docentes y estudiante para la realización de las prácticas o salidas pedagógicas, estos vehículos son: vans, bus escolar, camionetas y ambulancias. Cada vehículo está asignado a un conductor, a cada conductor se le pagan viáticos  de la siguiente forma, si el recorrido es fuera del dpto. por cada 50 km se le cancela un bono del 15% sobre su salario base, se le asigna dinero para combustible y pago de peajes según el recorrido, cada vehículo se identifica con la placa del mismo, se debe tener en cuenta que así mismo cada uno utiliza un tipo de combustible y tiene puesto para una cantidad de pasajeros, cuando la práctica es dentro del dpto., esta no dura más de 12 horas, las prácticas pueden ser de enfermería, ambientales, minas y desarrollo de software.

La universidad requiere que el software capture el salario del conductor, las salidas que realiza por mes, el valor de los viáticos, valor del consumo de combustible por cada vehículo y número de peajes pagados.

·         Propósito

ü  Permitir establecer objetivos satisfactorios entre de usuarios y a lo que el proyecto de software se refiere

ü  Definir y describir los requerimientos de operaciones, desempeño y calidad del software del sistema

ü  Este documento está dirigido a los involucrados en el desarrollo del proyecto, sirviendo como apoyo para dejar en claro los requerimientos funcionales, no funcionales y las diferentes condiciones que regirán el proyecto en todas las etapas de su desarrollo , estas especificaciones permitirán definir un marco de trabajo para la realización del sistema propuesto

ü  Ayudar a los usuarios finales entender exactamente cuáles son los beneficios del software y como se verán beneficiados del desarrollo del producto.

ü  Demostrar las cualidades del desarrollo y la estructura del proyecto

ü  Desarrollar un producto optimo y con las cualidades descritas en la entrevista de teck check

·         Alcance Del Proyecto

Se definirá en este documento los requerimientos funcionales y no funcionales del sistema a desarrollar, como lo es usabilidad, confiabilidad, desempeño ETC, al igual que los requerimientos funcionales del sistema a desarrollar , necesarios para los usuarios propuestos

ü  Identificación del problema

ü  Identificación de la solución

ü  Identificación de la amenazas y riesgos

ü  Objetivos del sistema a desarrollar

ü  Soporte del sistema desarrollado

ü  Mantenimiento del sistema

ü  Mejoras del sistema

4.      Especificación de requerimientos.

El software a Desarrollar  tiene, como objetivo principal, apoyar en la gestión de la universidad Se desea automatizar y controlar  fundamentalmente, la gestión de pagos de nómina determinando  el valor de los  sueldos y de los gastos incluidos durante el viaje que cada conductor realiza durante las jornadas de trabajo así como las actividades que realiza la universidad , también determinar la cantidad de vehículos   asociados a cada conductor .Primordialmente se realizara la entrevista la  de chequeo  con el personal involucrado en los procesos de nómina , programación de actividades conductores y supervisores. Esto tendrá como prioridad determinar, sueldos de los conductores dependiendo el vehículo automotor asociado a este, así como parámetros de consumo de combustible. Se contempla la posibilidad de utilizar aplicaciones en la para la recolección de datos asociado con (IoT), para agilizar la comunicación con los clientes, en este caso el parque automotor de la universidad.

  • Lista

de chequeo En la siguiente lista de chequeo se estableció la guía con la que trabaja un integrante del grupo en el desarrollo de Software en la empresa Sophos Banking 

TECK CHECK TECNICO

Nombre de la empresa

Nombre del Proyecto

Fecha

Criterio

SI

NO

NA

1. Correcto - La Especificación de un Requerimiento es correcta si, y solo si, el sistema/software alcanza todos y cada uno de los requerimientos en él especificados.

a. Desde el punto de vista del usuario, ¿se ha especificado el tiempo de respuesta esperado de todas las operaciones necesarias?

b. ¿Se han especificado otras consideraciones temporales tales como el tiempo de procesamiento, el de transferencia de datos o la tasa de transferencia?

c. ¿Se han especificado todas las tareas que debe realizar el sistema/software?

d. Para cada tarea especificada, ¿se ha detallado el contenido de datos/información utilizado por la tarea y el contenido de datos/información que se obtendrá como resultado de la misma?

e. ¿Se han establecido los requerimientos sobre la seguridad física?

f. ¿Se han establecido los requerimientos sobre la seguridad operacional?

g. ¿Se ha especificado la fiabilidad del sistema/software, incluyendo las consecuencias en el caso de que falle, la información vital a proteger en caso de caída, la detección de los errores o el proceso de recuperación?

h. ¿Las compensaciones establecidas entre los atributos que compiten son aceptables, por ejemplo, entre robustez y estado correcto?

i. ¿Se han definido las interfaces internas, como por ejemplo el software o el hardware?

j. ¿Se han definido las interfaces externas, como por ejemplo usuarios o hardware?

k. ¿Se ha incluido la definición de éxito? ¿Se ha incluido la definición de fracaso?

l. ¿Cada requerimiento es relevante para el problema y su solución?

2. No Ambiguo - Una Especificación de los Requerimientos es no ambigua si, y solo si, cada requerimiento especificado en ella posee exclusivamente una única interpretación.

a. ¿Los requerimientos se han especificado de forma suficientemente clara para que si se entregan a un grupo independiente para la implementación, dicho grupo sea capaz de entenderlos?

b. ¿Los requerimientos funcionales se encuentran separados de los no-funcionales?

c. ¿Los requerimientos están especificados de forma concisa, de modo que evitan la posibilidad de hacer múltiples interpretaciones de ellos?

d. ¿Todos los requerimientos evitan conflictos con otros requerimientos?

3. Completitud - Una Especificación de los Requerimientos es completa si, y solo si, incluye los siguientes elementos:

Todos los requerimientos significativos, ya sea relacionados con la funcionalidad, con el rendimiento, las limitaciones de diseño, los atributos o las interfaces externas.

Las definiciones de las respuestas del sistema/software a todas las clases posibles de datos de entrada en todos los tipos posibles de situaciones.

Etiquetas descriptivas y referencias a todas las figuras, tablas y diagramas de la Especificación de los Requerimientos, así como la definición de todos los términos y unidades de medición.

a. ¿Se han especificado todas las entradas al sistema/software, incluyendo su origen, su exactitud, su rango de valores y su frecuencia?

b. ¿Se han especificado todas las salidas al sistema/software, incluyendo su destino, su exactitud, su rango de valores, su frecuencia y su formato?

c. ¿Se han especificado todas las interfaces de comunicación, incluyendo su aceptación de la negociación, su control de errores y los protocolos de comunicación?

d. ¿Se ha realizado el análisis para identificar los requerimientos que no se han tenido en cuenta?

e. ¿Se han especificado las áreas de incompletitud para cuando la información no esté disponible?

f. ¿Los requerimientos son completos, tales que, si el producto satisface todos estos requerimientos, será aceptable?

g. ¿Es posible implementar todos y cada uno de los requerimientos?

h. ¿Se ha especificado la mantenibilidad del sistema/software, incluyendo la habilidad de respuesta a los cambios en el entorno operativo, las interfaces, la precisión, el rendimiento, y otras capacidades adicionales predecibles?

i. ¿Se han especificado los requerimientos para la comunicación entre los componentes del sistema/software?

j. ¿Se ha definido la funcionalidad y el comportamiento global de todo el sistema/software?

k. ¿Se han establecido de forma explícita y sin ambigüedades las restricciones, suposiciones y dependencias apropiadas?

l. ¿Se ha especificado adecuadamente la infraestructura tecnológica para el sistema/software?

m. ¿Se ha limitado el ámbito del sistema/software?

n. ¿Se han etiquetado de forma descriptiva todas las figuras, tablas y diagramas?

o. ¿Se han referenciado dentro del documento todas las figuras, tablas y diagramas?

p. ¿Se han definido de forma apropiada todos los términos y las unidades de medición?

4. Consistencia - La consistencia se refiere a la consistencia interna. Si la Especificación de los Requerimientos no concuerda con el resto de documentación de la organización y del proyecto, significa que no es correcta.

a. ¿Los requerimientos evitan la especificación del diseño?

b. ¿Se han especificado los requerimientos con un nivel de detalle consistente?

c. ¿Algunos de los requerimientos tienen que especificarse con mayor detalle?

d. ¿Algunos de los requerimientos deben ser especificados con menor detalle?

e. ¿Los requerimientos están en concordancia con el contenido del resto de documentación de la organización o del proyecto?

5. Categorizado por importancia y/o estabilidad - Una Especificación de los Requerimientos se categoriza por importancia y/o estabilidad si cada requerimiento particular especificado en ella posee un identificador que establece su importancia o estabilidad. Ejemplos de rangos de categorización incluyen esencial, condicional u opcional. La estabilidad puede ser especificada en términos del número de cambios esperados para un requerimiento.

a. ¿Los requerimientos poseen asociado un identificador para indicar la importancia o la estabilidad de un requerimiento en particular?

b. ¿Existen conflictos en relación a la categorización de la importancia y/o estabilidad de los requerimientos?

6. Verificable - Una Especificación de los Requerimientos es verificable si, y solo si, cada requerimiento especificado en ella es verificable. Un requerimiento es verificable si, y solo si, existe un proceso finito y rentable con el cual una persona o máquina puede comprobar que el sistema/software cumple con dicho requerimiento.

a. ¿El lenguaje y vocabulario con el que están escritos los requerimientos es entendible para los stakeholders? ¿Los stakeholders coinciden?

b. ¿Cada requerimiento puede ser probado? A partir de pruebas independientes, ¿puede ser posible determinar cuándo se satisface cada requerimiento?

7. Modificable - Una Especificación de los Requerimientos es modificable si, y solo si, su estructura y estilo son tales que cualquier cambio en los requerimientos puede realizarse de forma fácil, completa y consistente, conservando la estructura y el estilo.

a. ¿Los requerimientos se identifican de forma única?

b. ¿Se han consolidado los requerimientos redundantes?

c. ¿Cada requerimiento se ha especificado de forma separada, evitando requerimientos compuestos?

8. Trazable - Una Especificación de los Requerimientos es trazable si el origen de cada uno de sus requerimientos es claro y si facilita la referenciación de cada requerimiento en el desarrollo futuro o mejora la documentación.

a. ¿Puede trazarse cada requerimiento hacia su fuente de origen, como una declaración de su ámbito, una petición de cambio o una legislación?

b. ¿Se ha identificado cada requerimiento con el fin de facilitar su referenciación en el futuro desarrollo o en los esfuerzos de mejora?

c. ¿Cada requerimiento posee una referencia a los requerimientos previos del proyecto que están relacionados con él?

5.      Método de la investigación

Con el fin de cuantificar los costos y  medir  la  eficiencia  de  la  organización en cuanto a su programación y realización de actividades , se diseña el marco metodológico constara del siguiente levantamiento de información

  • Se deberá relacionar la estructura

vehicular de la universidad por tipo de vehículo así mismo sus características.

MARCA MODELO PLACA TIPO CONDUCTOR
  • Consumo de combustible y la representación

del costo para el parque automotor de la universidad según el  mercado actual.

MARCA MODELO LITROS DE COMBUSTIBLE COSTES DE COMBUSTIBLE
  • Es importante determinar la magnitud de la  operación 

de  la  universidad , conocer cuál es la frecuencia de  viajes diarios a diferentes  departamentos  del  país   y cuáles son los  más  comunes  para  la  prestación  del  servicio y así   determinar los viajes que realiza un conductor y la cantidad de peajes por los que tiene que transcurrir

VEHICULO PLACA DESTINO PEAJES CONDUCTOR

6.      Metodología adecuada para el desarrollo del proyecto.

El diseño de la propuesta del sistema de gestión de la solución que necesita la universidad exige el levantamiento de información y actualización detallada de los procesos y procedimientos actuales, y todo aquello que en ellos interviene, esto requiere la recopilación exhaustiva de información en las actas de chekeo que se detallaron anteriormente.

El software a Desarrollar  tiene, como objetivo principal, apoyar en la gestión de la universidad sea automatizar, fundamentalmente, la gestión de pagos de nómina que puede  determinar  sueldos y gastos incluidos durante el viaje de cada conductor , y de cada vehículo asociado a este,  por ende se establece la entrevista de chequeo la cual tiene como prioridad determinar la flota automotriz características de  las mismas, sueldos básicos  de los conductores dependiendo el vehículo automotor asociado a este, así como parámetros de consumo de combustible , cantidad de viajes por día ,  semana  , mes , departamentos visitados  , y la cantidad de peajes durante el desplazamiento a los puntos finales y de regreso ,  Se contempla la posibilidad de utilizar aplicaciones  para la recolección de datos asociado con (IoT) , para agilizar la comunicación  con los clientes , en este caso el parque automotor de la universidad .

Con esta premisa, es más sencillo comprender qué objetivo abarca el actual proyecto. Su misión es la integración en un sistema de las actividades de transporte relacionado con los costos y salarios total de cada conductor, permitiendo la asignación de rutas a  sus  transportistas.  De este modo, el presente proyecto  trata  de   proporcionar  un  proceso  de   calidad,  basado  en  un  equipamiento  de  nuevas  tecnologías,  para  el  funcionamiento   formal  de los gastos .

  • Método

de la investigación Con el fin  de  cuantificar  los  costos  y  calcular los sueldos de los conductores de la universidad   eficiencia  de  la  organización,  el  marco metodológico constara del siguiente levantamiento de información . Es importante debido a la magnitud de  la  operación  de  la  universidad , conocer cual es la frecuencia de  viajes diarios a diferentes  departamentos  del  país son  y con los  más  comunes  tanto de  origen  como  de destino  para  la  prestación  del  servicio que constara de.

  • DIACNOSTICO DE LA SITUACION ACTUAL

Como funciona la gestión actual

ü  Políticas y estrategias

ü  Procesos

ü  Procedimientos

ü  Recursos

ü  Responsables

ü  Gestión documental y de control

  • DISEÑO INTEGLRAL DE LA SOLUCION

Como satisfacer la necesidad del cliente

ü  Estrategias y lineamientos

ü  Procesos propuestos

ü  Recursos

ü  Responsables

ü  Nueva gestión documental

ü  Indicadores de gestión

ü  Tiempo de desarrollo

ü  Soporte de la integración

  • ANALISIS DE COSTOS

De cuanto seria la inversión

ü  Identificación de los recursos, a asignar al proyecto “financieros, técnicos, tecnológicos.

ü  Evaluación financiera

Basándose en estos requisitos, se procederá al modelado de la futura aplicación. Para ello, se utilizara la metodología a orientada a objetos UML .

En la metodología orientada a objetos se utiliza el UML , mediante el cual podemos representar diagramas  que permiten definir el sistema desde el punto de vista del usuario estableciendo las relaciones entre el futuro sistema y su entorno. Estas relaciones se establecen en forma de acciones del usuario y reacciones del sistema, Basándose en estos requisitos, se procederá al modelado de la futura aplicación bajo esta característica ya que Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. Ya  que es una combinación de varias notaciones orientadas a objetos diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.

7. FASES DE PROYECTO

Dentro de las fases del proyecto se encuentran:

Recolectar, analizar, aprobar y seguir la evolución de los requerimientos funcionales de la universidad y los requisitos de software a través de la vida del producto y/o servicio el desarrollo   requiere funcionales y los requisitos de software a través de la vida del producto. El desarrollo de los subprocesos se deberán iniciar una vez sea aprobado el proyecto y se llevara a cabo en un plazo el cual se determinar al final de la conciliación de los puntos de entrega con el Universidad , este tiempo en el cual se realizaran reuniones los cuales se evaluara el trabajo realizado durante el tiempo de ejecución del desarrollo ,por si  se asignan nuevas tareas y se establecen nuevas metas modificaciones o cambios en la estructura .

se llevará el control de las iteraciones planeadas (cabe recordar que una iteración equivale a una semana). la gestión de los requerimientos y requisitos de los módulos establecidos en los siguientes requisitos.

  • Documento visión. 
  • Especificación de requisitos.
  • Casos de uso.
  • Listas de Requerimientos. 

Bajo estas premisas se establecen Actas de trabajo donde se mencionan el conjunto de actividades que se van a realizar iterativamente en el desarrollo del proyecto y que son responsabilidad explicita de los analistas de las actividades realizadas durante la ejecución del desarrollo durante sus faces 

Análisis de Requisitos  

Extraer los requisitos del levantamiento de información que se diseñaron, de la primera etapa de recolección de información y de las entrevistas con el personal involucrado en los procesos cruciales para el desarrollo y ejecución. 

 Diseño y arquitectura

en esta etapa se definirá una subdivisión del sistema por funciones y la forma de comunicación para su interacción.

Actividades:

  • Definir los componentes del sistema
  • Refinar los casos de uso (textualmente y en diagrama)
  • Agregar detalles de implementación al modelo 
  • Desarrollar el modelo de interfaz
  • Desarrollar los modelos de control, persistencia y comunicación

Medios y Materiales a utilizar:

  • Hardware
  • Computador Pentium bajo Windows 7 X86 y X64 
  • Software
  • Rational Rose(Software para el modelado) 

Arquitectura

  • Organigrama del sistema
  • Selección de elementos interfaces y sus estructuras
  • Comportamiento de las integraciones entre componentes.
  • Composición de los elementos estructurales y de comportamiento en subsistemas
  • API de integración con GPS
  • Modelación vistas arquitectónicas 4+1
  • acoplamiento
  • Diagrama de componentes
  • Noción de dependencia y componentes 
  • Gui interfaz
  • Uso de interfaces 

esquema

Esquema
Esquema2
Esquema3

programación

Como se definió en la  arquitectura inicial se  y con la revisión de la   complejidad del proyecto  y a pesar de que el sistema en que se desarrollara no sea un lenguaje de programación, UML (Lenguaje Unificado Modelado) fue el que se seleccionó para realizar la integración ya que posee ventajas como  conectarse de manera directa a lenguajes de programación como Java, C++ o Visual Basic, se denomina como ingeniería directa el cual se podría obtener el código fuente partiendo de los modelos planteados en el levantamiento de información . El modelo de diseño está formado por los diagramas de clases de Diseño y los Diagramas de Secuencias. Diagrama de Clases de Diseño para la Gestión de Eventos

Diagrama

Diagrama

Pruebas

Revisar y comprobar que el software realice específicamente las tareas para lo cual fue diseñado de la forma indicada en los procesos de especificación de requisitos, la manera de realzar ducho proceso es probar de manera integral y después por separado la revisión de cada módulo del software,  para así llegar al objetivo para esto se deberá realizar pruebas por personal distinto al que desarrollo y programo el software. Se realizarán dos pruebas de esta manera,

  • la primera etapa estará conformada por personal inexperto y que desconozca el tema del software puntual entregado , para que pueda ser evaluada la documentación entregada, como lo son manuales  de producto ETC  ,y determinar que sea de calidad, y que los procesos descritos son tan claros que cualquier persona inexperta  puede entenderlos.
  • La segunda prueba estará conformada por personal de programación experta, que saben sin mayores indicaciones donde buscar posibles fallos , ya que ellos  pueden poner atención a detalles que usuarios normales o  inexpertos no considerarían al momento de probarlo.

Documentación

Se entregará y evidenciará el paso a paso con los procesos del desarrollo del software implementado y de la gestión del proyecto, pasando por cada uno del moldeado (UML), manuales técnicos, manuales de usuario, pruebas planes de mantenimiento, etc.; todo con el propósito de eventuales correcciones, mantenimiento futuro, ampliaciones al sistema y usabilidad.

Mantenimiento

Se elaborará un plan de mantenimiento para mantener y mejorar el Software y así poder enfrentar errores descubiertos, así como nuevos requisitos, parches, fix y mejoras para mantener actualizado el producto y funcionando de manera adecuada.


8. Cómo Asegurar La Calidad Del Producto.

Este desarrollo está enmarcado en un ambiente altamente competitivo donde La consecución de la calidad para la universidad  implica que se trabaje con efectividad compromiso e integridad esto hace que sea un factor determinante para la empresa que quiera estar a la vanguardia con altos estándares de competitividad se deben ofrecer productos que se cumplan con estándares internacionales , ya que para lograr tener un buen reconocimiento como desarrolladores de proyectos de Software esto  se consigue bajo la certificación de las normas internacionales  de la ISO 9000, actuando sobre dos aspectos del proyecto: 

Eficacia: hacer que lo planificado y lo realizado se aproximen al máximo en la ejecución, que la sintonía entre lo que se planifico durante toda la ejecución del proyecto consiga que la universidad perciba la calidad adecuada en los productos que recibe y el acompañamiento que se realice.

Eficiencia: El principal objetivo es reducir el costo, elevar la productividad durante la ejecución del proyecto, esto tiene como fin entregar un producto de calidad en la industria del software y mejorar la calidad para lograr un producto competitivo que se ajuste a los requerimientos de calidad establecidos por la universidad.

En dicho proceso de la calidad se tendrá que dividir en una serie de subprocesos que nos ayudaran a cubrir las necesidades que queremos abordar.

Dentro de los procesos de aseguramiento de la calidad tenemos tres, que particularmente para este proyecto son los más importantes.

Planificación: 

El principal objetivo de la planificación en este tipo de proyectos de desarrollo de software es ordenar el qué hacer durante el proyecto y asignar adecuadamente los recursos y tareas para cumplir los objetivos propuestos dúrate los cronogramas del proyecto previamente analizados y socializados con cada uno de los responsables de las actividades estos son:

  • Organizar actividades el personal involucrado.
  • Minimizar tiempo y costos involucrados.
  • Maximizar el uso de recursos disponibles.
  • Medir el avance.
  • Mejorar la comunicación.


La planificación es una tarea que se desarrolla al inicio del proyecto, pero rige el resto de las fases. Una buena planificación inicial ayudará a que las metas propuestas se cumplan y que los eventuales inconvenientes sean abordados de mejor forma y bajo circunstancias casi controladas.


Evaluación :

En el proceso de evaluación de las fases del proyecto por lo regular se crea un equipo mixto por parte de la universidad y personal encargado del proceso de desarrollo, esto como tal  para identificar problemas, proponer elementos de solución , como tal evaluación de enfoques cronogramas tiempos , revisión de los requisitos preliminares del inicio del proyecto , sus directrices básicas son :

  • Reuniones periódicas entre técnicos y personal de la universidad
  • Establecimientos de reglas para la preparación y ejecución de actividades
  • Agendas con cronogramas puntuales bajo normas internacionales (ITL)
  • Reuniones informales para el desarrollo de flujos de lluvia de ideas 
  • Evaluación de los procesos de calidad
  • Evaluación de las herramientas para el desarrollo del proyecto

Comunicación:

Cuando cualquiera de los procesos anteriores no se estén cumpliendo de acuerdo a los cronogramas y fases del proyecto es necesario realizar reuniones, comités para volver a reorganizarlos y encauzarlos de acuerdo a los cronogramas de trabajo , y así tomar las medidas oportunas para realizar lo planificado , ya que si no se toman medidas adecuadas , el proyecto puede estancarse y tomar más tiempo de lo debido y aumenten los costos por lo que  no conseguiría  su objetivo de manera correcta.

En la comunicación se pueden abordar todos los temas de las fases e implementación del proyecto y realizar una medición del cómo vamos y en qué áreas de los subprocesos debemos mejorar o se debe poner más atención para que las demás fases estén alineadas durante el desarrollo ,es de común acuerdo determinar lo importante que es para el desarrollo efectivo en su última ejecución en la cadena de procesos ,  que mínimo estos tres subprocesos se cumplan a la medida  , ya que por ende  el proceso  de aseguramiento de calidad no podría cumplirse y el propósito del sistema de gestión de calidad estaría en estado fallido,

9. CONCLUSIONES

Para conseguir el éxito en cualquier desarrollo de software es esencial la compresión de los requisitos del usuario y lo importante de la documentación , de los principales formatos pero sobre todo lo bien analizado de la situación y de las características que conllevan a un desarrollo exitoso, esta es la tarea más extensa que se tiene sobre el proyecto porque de esta depende que se entregue lo que el cliente ha solicitado y con las mejoras posteriores que se puedan identificar en el proceso pos- desarrollo ,  En base al análisis de los resultados obtenidos podemos concluir que se cumple el objetivo de determinar la estructura que se necesita para la implementación  de la nueva herramienta , así como la documentación procesos subprocesos que implican el desarrollo de un proyecto y de cómo se deben alinear las dos partes para logran un bien común durante un proceso de desarrollo.

Finalmente, se debe indicar que esta fase es posiblemente la más costosa (temporalmente) en el desarrollo de un producto software. Esto se debe a que, en general, el cliente no sabe realmente lo que quiere y requiere la ayuda de los analistas para concretar las funciones que realmente se han de implementar. Por tanto, de la calidad del documento de ERS dependerá el desarrollo y calidad del producto final.

10. Referencias

http://es.ingenieria-de-requerimientos.wikia.com/wiki/Ingenieria_de_requerimientos_Wiki

[Davis A., 1995]: Davis A. 201 Principles of Software Development. 1ª ed.

McGraw-Hill, 1995

Hayes, Be (1999). Como medir la satisfacción del cliente. Desarrollo y utilización de

cuestionarios. Gestión 2000. Barcelona. España

KULAK Daryl, GUINEY Eamonn. Use Cases: Requirements in Context, Segunda Edicion, Addison-Wesley Professional, 2004.

Gestión de proyectos de Software 

https://www.inf.utfsm.cl/~guerra/publicaciones/Gestion%20de%20Proyectos%20de%20Software.pdf

aseguramiento de calidad de proyectos de Software

http://www.cioal.com/2016/06/16/asegurar-calidad-proyecto-software/

norma iso9001 para el desarrollo de Software

https://www.nueva-iso-9001-2015.com/2017/02/norma-iso-9001-desarrollo-software/

metodología orientada a obejot UML

https://www.lucidchart.com/pages/es/qu%C3%A9-es-el-lenguaje-unificado-de-modelado-uml