Informe de ppp desarrollo de software

UNIVERSIDAD NACIONAL
HERMILIO VALDIZÁN
FACULTAD DE CIENCIAS AGRARIAS
ESCUELA ACADÉMICO PROFESIONAL
DE INGENIERÍA AGROINDUSTRIAL
INFORME DE PRÁCTICAS PRE-PROFESIONALES
“DESARROLLO DE SOFTWARE, PARA CONTROLAR Y MEJORAR LOS
PROCESOS AGROINDUSTRIALES”
EJECUTOR : SALAZAR CANO, Franklin
ASESOR : Mg. Gregorio Cisneros Santos
LUGAR DE EJECUCIÓN:Centro de Innovación y Emprendimiento Agroindustrial
FECHA DE EJECUCIÓN: Del 5 de enero al 5 de abril del 2015.
HUÁNUCO – PERÚ
2015

3
DEDICATORIA
Con el más grande aprecio de mi corazón este proyecto es dedicado a mis padres
por darme su inmenso apoyo económico como moral y guiarme por el sendero de
los valores y del éxito.

4
AGRADECIMIENTO
Primero agradezco a Dios por darnos oportunidad de contemplar todas las
mañanas la aurora del alegre amanecer, y agradezco a mis profesores por
brindarme cada día sus conocimientos y así hacer posible la realidad de este
proyecto.

5
RESUMEN
El desarrollo de software abarca una serie de procedimientos, normas, reglas,
etc., que deben estar estrictamente analizados para luego procesarlos y así
obtener un producto final; para el desarrollo del presente software se hemos
tenido que seguir todas las instrucciones que delatan las normas y estándares
para la creación de softwares.
En la creación del presente software hemos abarcado varios aspectos, como es el
caso de integración de sistemas para procesar y desplegar datos y referencias
para elaborar un determinado producto ya sea alimentario o no alimentario, donde
estos sistemas han sido codificados en un determinado orden como por ejemplo
para realizar la formulación, para mostrar el diagrama de flujo, para la descripción
del proceso, todo esto está correctamente estructurado para que el usuario puede
interactuar de manera armoniosa buscando el proceso que quiera realizar y el
software inmediatamente le responda al pedido, y si el pedido no está declarado
en el programa, está controlado la parte de excepciones para conducir al usuario
a un ventana de disculpas y ofrecer otras opciones similares. También están
integrados otros aplicativos secundarios como es balance de materia, cálculo de
costos, cálculo de envases, etc., que ayudaran a dinamizar las operaciones.
En el desarrollo del software también se han incorporado sistemas integrados,
para realizar una diversidad de operaciones a nivel de ingeniería, todas estas
operaciones están basados en fórmulas que han sido recolectados de diversos
libros reconocidos dentro de la ciencias de la ingeniería, luego han sido cargados
en forma de algoritmos al programa de esa manera facilitar a los usuarios de
realizar operaciones tan tediosos que toman muchísimo tiempo para su cálculo,
cosa que con el software solo tomara unos cuantos segundos para obtener el
resultado, y hablamos de un resultado muy confiable ya que la programación casi
nunca falla.
También se ha incorporado al software la parte de soporte técnico, para resolver
todas las dudas, insatisfacciones, sugerencias, de los usuarios, esto a través de
una página web desarrollada paralelamente con el software.

6
ABSTRACT
Software development includes a range of procedures, rules, regulations, etc.,
which must be strictly analyzed to then process and obtain a final product; for the
development of this software have had to follow all the instructions that reveal the
norms and standards for building software.
In the creation of this software we have covered several aspects, such as systems
integration to process and display data and references to produce a particular
product either food or non-food, where these systems have been encoded in a
particular order as example for the formulation, to show flowchart for describing
the process, all this is properly structured so that the user can interact
harmoniously searching the process you want to perform and the software will
immediately respond to the request, and if the order is not declared in the
program, is controlled part of exceptions to lead the user to a window apologize
and offer similar options. Are also integrated other side applications as is material
balance, costing, calculation of containers, etc., to help streamline operations.
In software development have also incorporated integrated systems to perform a
variety of operations at the engineering level, all these operations are based on
formulas that have been collected from various books recognized within the
engineering sciences, then they have been loaded as algorithms to program thus
facilitate users to perform such tedious operations that take a long time for its
calculation, which the software will only take a few seconds to get the result, and
we talked about a very reliable result because programming almost never fails.
Has also joined the party software support to resolve all doubts, dissatisfaction,
suggestions, users, this through a website developed in parallel with the software.

7
ÍNDICE
Contenido
DEDICATORIA........................................................................................................................... 3
AGRADECIMIENTO ................................................................................................................... 4
RESUMEN ................................................................................................................................ 5
ABSTRACT................................................................................................................................ 6
I. INTRODUCCIÓN............................................................................................................ 9
II. OBJETIVOS...................................................................................................................10
2.1. Objetivo general ..................................................................................................10
2.2. Objetivos específicos...........................................................................................10
III. GENERALIDADES DE LA EMPRESA..........................................................................10
3.1. Antecedentes............................................................Error! Bookmark not defined.
3.2. Misión y visión ..........................................................Error! Bookmark not defined.
3.3. Razón social.............................................................Error! Bookmark not defined.
3.4. Ubicación..................................................................Error! Bookmark not defined.
3.5. Recursos humanos...................................................Error! Bookmark not defined.
IV. MARCO TEÓRICO........................................................................................................12
4.1. FUNDAMENTACIÓN TEÓRICA: .......................................................................12
SOFTWARE.......................................................................................................................12
a.Etimología...........................................................................................................12
b.Definición de software .........................................................................................13
c.Clasificación del software......................................................................................13
d.Proceso de creación del software..........................................................................15
e.Carácter evolutivo del software[17]
.........................................................................39
V. MATERIALES Y MÉTODOS.........................................................................................41
5.1. Lugar y fecha de ejecución ................................................................................41
5.2. Materiales y equipos ..........................................................................................41
5.2.1.Materiales......................................................................................................41
5.2.2.Equipos..........................................................................................................41
5.3. Conducción de las prácticas pre-profesionales.................................................41
Diagrama de desarrollo Nº 1: ÁREAS DE DESARROLLO DEL SOFTWARE:...............................42

8
Diagrama de desarrollo Nº 2: ÓRDENES DE DESARROLLO DEL SOFTWARE:...........................43
Diagrama de desarrollo Nº 3: IMPLEMENTACIÓN GRÁFICA.................................................47
Diagrama de desarrollo Nº 4: Diagrama de flujo de desarrollo del software.........................48
5.3.1.Definición de requerimientos ......................................................................49
5.3.2.Análisis y diseño del software.....................................................................49
5.3.3.Codificación del software............................................................................50
5.3.4.Integración y prueba del sistema................................................................50
5.3.5.Instalación y paso a producción .................................................................51
5.3.6.Operación y mantenimiento........................................................................51
VI. RESULTADOS...............................................................................................................52
VII. DISCUSIÓN...................................................................................................................53
VIII. CONCLUSIÓN...............................................................................................................56
IX. RECOMENDACIÓN ......................................................................................................57
X. LITERATURA CITADA..................................................................................................58
a. Libros .........................................................................................................................58
b. Artículos y revistas.....................................................................................................59
XI. ANEXOS...........................................................................................................................60
ANEXO Nº 1: Referencias del marco teórico................................................................60
ANEXO Nº 2: Fotografías..............................................................................................62

9
I. INTRODUCCIÓN
El software agroindustrial es un programa diseñado para el campo agroindustrial,
con aplicativos que permitan guiarnos de manera clara y entendible al momento
de usarlo, este software tiene la función de procesar, analizar y devolver los datos
pedidos por el usuario como puede ser la elaboración de un determinado producto
alimentario o no alimentario o el cálculo de un determinado problema matemático.
El software agroindustrial busca mejorar la productividad dentro de las empresas,
reduciendo los tiempos y costos de producción.
El software agroindustrial es desarrollado con algoritmos que nacen de los
mismos procesos de los productos (alimentarios y no alimentarios).
Un software es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados, que forman parte de las operaciones de un
sistema de computación.
Extraído del estándar 729 del IEEE
El término «software» fue usado por primera vez en este sentido por John W.
Tukey en 1957. En la ingeniería de software y las ciencias de la computación, el
software es toda la información procesada por los sistemas informáticos:
programas y datos.
El concepto de leer diferentes secuencias de instrucciones (programa) desde la
memoria de un dispositivo para controlar los cálculos fue introducido por Charles
Babbage como parte de su máquina diferencial. La teoría que forma la base de la
mayor parte del software moderno fue propuesta por Alan Turing en su ensayo de
1936, «Los números computables», con una aplicación al problema de decisión.

10
II. OBJETIVOS
2.1. Objetivo general
 Desarrollar un Software para mejorar controlar y monitorear los
procesos agroindustriales.
2.2. Objetivos específicos
 Desarrollar un software para mejorar los procesos agroindustriales
 Desarrollar un Software que nos permita incrementar la
productividad dentro de las empresas.
 Desarrollar un software con sistemas de cálculos integrados, que
permitan ingresar, procesar y desplegar diferentes tipos datos.
III. GENERALIDADES DE LA EMPRESA
Objetivo.
El Centro de Innovación y Emprendimiento de la EAP de Ingeniería Agroindustrial
de la UNHEVAL tiene como objetivo promover las iniciativas de innovación
tecnológica agroindustrial y la gestión del emprendimiento en la comunidad
universitaria.
Dirección.
de la UNHEVAL se encuentra ubicado en la sede de la EAP de Ingeniería
Agroindustrial, Pabellón de la Facultad de Ciencias Agrarias en Cayhuayna,
distrito de Pillcomarka, provincia y departamento de Huánuco.

11
Responsable.
de la UNHEVAL está a cargo del Mg. Gregorio Cisneros Santos, docente de la
EAP de Ingeniería Agroindustrial de la UNHEVAL.
Ambientes e Infraestructura.
de la UNHEVAL cuenta con una oficina donde desarrolla sus labores de extensión
universitaria y proyección social ahora denominada Responsabilidad Social
Universitaria, para ello cuenta con el soporte técnico adecuado para dicho
propósito.
Principales Actividades desarrolladas.
Entre las actividades desarrolladas por el Centro de Innovación y Emprendimiento
de la EAP de Ingeniería Agroindustrial de la UNHEVAL tenemos:
 Taller “Gestión del Emprendimiento” desarrollado con los alumnos del
curso de Agronegocios 2014 EAPIA.
 Feria 50° Aniversario de la Cámara de Comercio e Industrias de Huánuco,
2014.
 Feria de Competitividad Agroindustrial organizada por la Cámara de
Comercio e Industria de Huánuco, 2014.
 Curso Taller “Promoviendo la Cultura del Emprendimiento” dirigido a los
alumnos de la EAPIA, 2014.
 VI Agroforum y II Feria Agroindustrial Universitaria organizado por la
Universidad Nacional Mayor de San Marcos, 2015.

12
IV. MARCO TEÓRICO
4.1. FUNDAMENTACIÓN TEÓRICA:
SOFTWARE
Se conoce como software[1] al equipamiento lógico o soporte lógico de
un sistema informático, que comprende el conjunto de los
componentes lógicos necesarios que hacen posible la realización de tareas
específicas, en contraposición a los componentes físicos que son
llamados hardware.
Los componentes lógicos incluyen, entre muchos otros, las aplicaciones
informáticas; tales como el procesador de texto, que permite al usuario realizar
todas las tareas concernientes a la edición de textos; el llamado software de
sistema, tal como el sistema operativo, que básicamente permite al resto de los
programas funcionar adecuadamente, facilitando también la interacción entre los
componentes físicos y el resto de las aplicaciones, y proporcionando
una interfaz con el usuario. [1]
El anglicismo "software" es el más ampliamente difundido al referirse a este
concepto, especialmente en la jerga técnica; en tanto que el término sinónimo
«logicial», derivado del término francés logiciel, es utilizado mayormente en
países y zonas de influencia francesa.
a. Etimología
Software es una palabra proveniente del inglés (literalmente: partes blandas o
suaves), que en español no posee una traducción adecuada al contexto, por lo
cual se la utiliza asiduamente sin traducir y así fue admitida por la Real Academia
Española (RAE).[2] Aunque puede no ser estrictamente lo mismo, suele sustituirse
por expresiones tales como programas (informáticos) o aplicaciones (informáticas)
o soportes lógicos.[3]
Software es lo que se denomina producto en Ingeniería de Software.[4]

13
b. Definición de software
Existen varias definiciones similares aceptadas para software, pero
probablemente la más formal sea la siguiente:
Es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados, que forman parte de las operaciones de un
sistema de computación.
Extraído del estándar 729 del IEEE[5]
Considerando esta definición, el concepto de software va más allá de los
programas de computación en sus distintos estados: código
fuente, binario o ejecutable; también su documentación, los datos a procesar e
incluso la información de usuario forman parte del software: es decir, abarca todo
lo intangible, todo lo «no físico» relacionado.
El término «software» fue usado por primera vez en este sentido por John W.
Tukey en 1957. En la ingeniería de software y las ciencias de la computación, el
software es toda la información procesada por los sistemas informáticos:
programas y datos. [1]
El concepto de leer diferentes secuencias de instrucciones (programa) desde
la memoria de un dispositivo para controlar los cálculos fue introducido
por Charles Babbage como parte de su máquina diferencial. La teoría que forma
la base de la mayor parte del software moderno fue propuesta por Alan Turing en
su ensayo de 1936, «Los números computables», con una aplicación al problema
de decisión. [2]
c. Clasificación del software
Si bien esta distinción es, en cierto modo, arbitraria, y a veces confusa, a los fines
prácticos se puede clasificar al software en tres grandes tipos:

14
 Software de sistema: Su objetivo es desvincular adecuadamente al
usuario y al programador de los detalles del sistema informático en
particular que se use, aislándolo especialmente del procesamiento referido
a las características internas de: memoria, discos, puertos y dispositivos de
comunicaciones, impresoras, pantallas, teclados, etc. El software de
sistema le procura al usuario y programador adecuadas interfaces de alto
nivel, controladores, herramientas y utilidades de apoyo que permiten el
mantenimiento del sistema global.[8] Incluye entre otros:
o Sistemas operativos
o Controladores de dispositivos
o Herramientas de diagnóstico
o Herramientas de Corrección y Optimización
o Servidores
o Utilidades
 Software de programación: Es el conjunto de herramientas que permiten
al programador desarrollar programas informáticos, usando diferentes
alternativas y lenguajes de programación, de una manera práctica.[5]
Incluyen básicamente:
o Editores de texto
o Compiladores
o Intérpretes
o Enlazadores
o Depuradores
o Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores
herramientas, usualmente en un entorno visual, de forma tal que el
programador no necesite introducir múltiples comandos para
compilar, interpretar, depurar, etc. Habitualmente cuentan con una
avanzada interfaz gráfica de usuario (GUI).
 Software de aplicación: Es aquel que permite a los usuarios llevar a cabo
una o varias tareas específicas, en cualquier campo de actividad
susceptible de ser automatizado o asistido, con especial énfasis en los
negocios. [8] Incluye entre muchos otros:

15
o Aplicaciones para Control de sistemas y automatización industrial
o Aplicaciones ofimáticas
o Software educativo
o Software empresarial
o Bases de datos
o Telecomunicaciones (por ejemplo Internet y toda su estructura
lógica)
o Videojuegos
o Software médico
o Software de cálculo numérico y simbólico.
o Software de diseño asistido (CAD)
o Software de control numérico (CAM)
d. Proceso de creación del software
Se define como proceso al conjunto ordenado de pasos a seguir para llegar a la
solución de un problema u obtención de un producto, en este caso particular, para
lograr un producto software que resuelva un problema específico.[9]
El proceso de creación de software puede llegar a ser muy complejo,
dependiendo de su porte, características y criticidad del mismo. Por ejemplo la
creación de un sistema operativo es una tarea que requiere proyecto, gestión,
numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo,
si se trata de un sencillo programa (por ejemplo, la resolución de una ecuación de
segundo orden), éste puede ser realizado por un solo programador (incluso
aficionado) fácilmente. Es así que normalmente se dividen en tres categorías
según su tamaño (líneas de código) o costo: de «pequeño», «mediano» y «gran
porte». Existen varias metodologías para estimarlo, una de las más populares es
el sistema COCOMO que provee métodos y un software (programa) que calcula y
provee una aproximación de todos los costos de producción en un «proyecto
software» (relación horas/hombre, costo monetario, cantidad de líneas fuente de
acuerdo a lenguaje usado, etc.).

16
Considerando los de gran porte, es necesario realizar complejas tareas, tanto
técnicas como de gerencia, una fuerte gestión y análisis diversos (entre otras
cosas), la complejidad de ello ha llevado a que desarrolle una ingeniería
específica para tratar su estudio y realización: es conocida como Ingeniería de
Software.
En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un
avezado analista-programador solitario) pueden realizar la tarea. Aunque, siempre
en casos de mediano y gran porte (y a veces también en algunos de pequeño
porte, según su complejidad), se deben seguir ciertas etapas que son necesarias
para la construcción del software. Tales etapas, si bien deben existir, son flexibles
en su forma de aplicación, de acuerdo a la metodología o proceso de
desarrollo escogido y utilizado por el equipo de desarrollo o por el analista-
programador solitario (si fuere el caso).[9]
Los «procesos de desarrollo de software» poseen reglas preestablecidas, y
deben ser aplicados en la creación del software de mediano y gran porte, ya que
en caso contrario lo más seguro es que el proyecto no logre concluir o termine sin
cumplir los objetivos previstos, y con variedad de fallos inaceptables (fracasan, en
pocas palabras). Entre tales «procesos» los hay ágiles o livianos (ejemplo XP),
pesados y lentos (ejemplo RUP), y variantes intermedias. Normalmente se aplican
de acuerdo al tipo y porte del software a desarrollar, a criterio del líder (si lo hay)
del equipo de desarrollo. Algunos de esos procesos son Programación
Extrema (en inglés Xtreme Programming o XP), Proceso Unificado de
Rational (en inglés Rational Unified Process o RUP), Feature Driven Development
(FDD), etc.
Cualquiera sea el «proceso» utilizado y aplicado al desarrollo del software (RUP,
FDD, XP, etc.), y casi independientemente de él, siempre se debe aplicar un
«modelo de ciclo de vida».[6]

17
Se estima que, del total de proyectos software grandes emprendidos, un 28%
fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son
totalmente exitosos. [7]
Cuando un proyecto fracasa, rara vez es debido a fallas técnicas, la principal
causa de fallos y fracasos es la falta de aplicación de una buena metodología o
proceso de desarrollo. Entre otras, una fuerte tendencia, desde hace pocas
décadas, es mejorar las metodologías o procesos de desarrollo, o crear nuevas y
concientizar a los profesionales de la informática a su utilización adecuada.
Normalmente los especialistas en el estudio y desarrollo de estas áreas
(metodologías) y afines (tales como modelos y hasta la gestión misma de los
proyectos) son los ingenieros en software, es su orientación. Los especialistas en
cualquier otra área de desarrollo informático (analista, programador, Lic. en
informática, ingeniero en informática, ingeniero de sistemas, etc.) normalmente
aplican sus conocimientos especializados pero utilizando modelos, paradigmas y
procesos ya elaborados.
Es común para el desarrollo de software de mediano porte que los equipos
humanos involucrados apliquen «metodologías propias», normalmente un híbrido
de los procesos anteriores y a veces con criterios propios.[4]
El proceso de desarrollo puede involucrar numerosas y variadas tareas,[6] desde
lo administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento.
Pero, casi rigurosamente, siempre se cumplen ciertas etapas mínimas; las que
se pueden resumir como sigue:
 Captura, elicitación[8] , especificación y análisis de requisitos (ERS)
 Diseño
 Codificación
 Pruebas (unitarias y de integración)
 Instalación y paso a producción
 Mantenimiento

18
En las anteriores etapas pueden variar ligeramente sus nombres, o ser más
globales, o contrariamente, ser más refinadas; por ejemplo indicar como una
única fase (a los fines documentales e interpretativos) de «análisis y diseño»; o
indicar como «implementación» lo que está dicho como «codificación»; pero en
rigor, todas existen e incluyen, básicamente, las mismas tareas específicas.
d.1. Modelos de proceso o ciclo de vida
Para cada una de las fases o etapas listadas en el ítem anterior, existen sub-
etapas (o tareas). El modelo de proceso o modelo de ciclo de vida utilizado para
el desarrollo, define el orden de las tareas o actividades involucradas,[6] también
define la coordinación entre ellas, y su enlace y realimentación. Entre los más
conocidos se puede mencionar: modelo en cascada o secuencial, modelo
espiral, modelo iterativo incremental. De los antedichos hay a su vez algunas
variantes o alternativas, más o menos atractivas según sea la aplicación requerida
y sus requisitos.[7]
d.1.1. Modelo cascada
Este, aunque es más comúnmente conocido como modelo en cascada es también
llamado «modelo clásico», «modelo tradicional» o «modelo lineal secuencial».
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un
previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o
rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a
escasos y pequeños sistemas a desarrollar. En estas circunstancias, el paso de
una etapa a otra de las mencionadas sería sin retorno, por ejemplo pasar del
diseño a la codificación implicaría un diseño exacto y sin errores ni probable
modificación o evolución: «codifique lo diseñado sin errores, no habrá en absoluto
variantes futuras». Esto es utópico; ya que intrínsecamente el software es de
carácter evolutivo,[9]cambiante y difícilmente libre de errores, tanto durante su
desarrollo como durante su vida operativa.[6]

19
Fig. 1 - Modelo cascada puro o secuencial para el ciclo de vida del software.
Algún cambio durante la ejecución de una cualquiera de las etapas en este
modelo secuencial implicaría reiniciar desde el principio todo el ciclo completo, lo
cual redundaría en altos costos de tiempo y desarrollo. La Figura 2 muestra un
posible esquema del modelo en cuestión.[6]
Fig. 2 - Modelo cascada realimentado para el ciclo de vida
Lo dicho es, a grandes rasgos, la forma y utilización de este modelo, uno de los
más usados y populares.[6] El modelo cascada realimentado resulta muy atractivo,
hasta ideal, si el proyecto presenta alta rigidez (pocos cambios, previsto no
evolutivo), los requisitos son muy claros y están correctamente especificados.[10]

20
d.1.2. Modelos evolutivos
El software evoluciona con el tiempo.[11] [9] Los requisitos del usuario y del
producto suelen cambiar conforme se desarrolla el mismo. Las fechas de
mercado y la competencia hacen que no sea posible esperar a poner en el
mercado un producto absolutamente completo, por lo que se aconsejable
introducir una versión funcional limitada de alguna forma para aliviar las presiones
competitivas.
En esas u otras situaciones similares los desarrolladores necesitan modelos de
progreso que estén diseñados para acomodarse a una evolución temporal o
progresiva, donde los requisitos centrales son conocidos de antemano, aunque no
estén bien definidos a nivel detalle.
En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta
la naturaleza evolutiva del software,[11] se plantea como estático, con requisitos
bien conocidos y definidos desde el inicio.[6]
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez
más completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar más allá, durante la fase de operación.
Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de los más
conocidos y utilizados del tipo evolutivo.[10]
d.1.2.1. Modelo iterativo incremental
En términos generales, se puede distinguir, en la Figura 3, los pasos generales
que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo
de vida seleccionado, se identifican claramente dichos pasos. La descripción del
sistema es esencial para especificar y confeccionar los distintos incrementos
hasta llegar al producto global y final. Las actividades concurrentes
(especificación, desarrollo y validación) sintetizan el desarrollo pormenorizado de
los incrementos, que se hará posteriormente.

21
Fig. 3 - Diagrama genérico del desarrollo evolutivo incremental.
El incremental es un modelo de tipo evolutivo que está basado en varios ciclos
Cascada Realimentados aplicados repetidamente, con una filosofía iterativa.[10] En
la Figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal,
para obtener finalmente el esquema del modelo de ciclo de vida Iterativo
Incremental, con sus actividades genéricas asociadas. Aquí se observa
claramente cada ciclo cascada que es aplicado para la obtención de un
incremento; estos últimos se van integrando para obtener el producto final
completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la Figura 4 se muestra como secuencial puro.
Fig. 4 - Modelo iterativo incremental para el ciclo de vida del software.

22
d.1.2.2. Modelo espiral
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemáticos del Modelo Cascada. Proporciona potencial para
desarrollo rápido de versiones incrementales. En el modelo Espiral el software se
construye en una serie de versiones incrementales. En las primeras iteraciones la
versión incremental podría ser un modelo en papel o bien un prototipo. En las
últimas iteraciones se producen versiones cada vez más completas del sistema
diseñado.[6] [10]
El modelo se divide en un número de Actividades de marco de trabajo, llamadas
«regiones de tareas». En general existen entre tres y seis regiones de tareas
(hay variantes del modelo). En la Figura 6 se muestra el esquema de un Modelo
Espiral con 6 regiones. En este caso se explica una variante del modelo original
de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más
reciente.
Fig. 5 - Modelo espiral para el ciclo de vida del software.

23
Las regiones definidas en el modelo de la figura son:
 Región 1 - Tareas requeridas para establecer la comunicación entre el
cliente y el desarrollador.
 Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra
información relacionada con el proyecto.
 Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de
gestión del proyecto.
 Región 4 - Tareas para construir una o más representaciones de la
aplicación software.
 Región 5 - Tareas para construir la aplicación, instalarla, probarla y
proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
 Región 6 - Tareas para obtener la reacción del cliente, según la evaluación
de lo creado e instalado en los ciclos anteriores.
d.2. Etapas en el desarrollo del software
d.2.1. Captura, análisis y especificación de requisitos
Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se
realiza, y, según el modelo de proceso adoptado, puede casi terminar para pasar
a la próxima etapa (caso de Modelo Cascada Realimentado) o puede hacerse
parcialmente para luego retomarla (caso Modelo Iterativo Incremental u otros de
carácter evolutivo).
En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y
especifican las características funcionales y no funcionales que deberá cumplir el
futuro programa o sistema a desarrollar.
Las bondades de las características, tanto del sistema o programa a desarrollar,
como de su entorno, parámetros no funcionales y arquitectura dependen
enormemente de lo bien lograda que esté esta etapa. Esta es, probablemente, la
de mayor importancia y una de las fases más difíciles de lograr certeramente,

24
pues no es automatizable, no es muy técnica y depende en gran medida de la
habilidad y experiencia del analista que la realice.
Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy
subjetivos y es difícil de modelar con certeza o aplicar una técnica que sea «la
más cercana a la adecuada» (de hecho no existe «la estrictamente adecuada»).
Si bien se han ideado varias metodologías, incluso software de apoyo, para
captura, elicitación y registro de requisitos, no existe una forma infalible o
absolutamente confiable, y deben aplicarse conjuntamente buenos criterios y
mucho sentido común por parte del o los analistas encargados de la tarea; es
fundamental también lograr una fluida y adecuada comunicación y comprensión
con el usuario final o cliente del sistema.
El artefacto más importante resultado de la culminación de esta etapa es lo que
se conoce como especificación de requisitos software o simplemente documento
ERS.
Como se dijo, la habilidad del analista para interactuar con el cliente es
fundamental; lo común es que el cliente tenga un objetivo general o problema que
resolver, no conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe
con precisión qué debería hacer el producto software (qué y cuantas funciones)
ni, mucho menos, cómo debe operar. En otros casos menos frecuentes, el cliente
«piensa» que sabe precisamente lo que el software tiene que hacer, y
generalmente acierta muy parcialmente, pero su empecinamiento entorpece la
tarea de elicitación. El analista debe tener la capacidad para lidiar con este tipo de
problemas, que incluyen relaciones humanas; tiene que saber ponerse al nivel del
usuario para permitir una adecuada comunicación y comprensión.
Escasas son las situaciones en que el cliente sabe con certeza e incluso con
completitud lo que requiere de su futuro sistema, este es el caso más sencillo
para el analista.

25
Las tareas relativas a captura, elicitación, modelado y registro de requisitos,
además de ser sumamente importante, puede llegar a ser dificultosa de lograr
acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al
proceso y metodologías para llevar a cabo este conjunto de actividades
normalmente se las asume parte propia de la Ingeniería de Software, pero dada la
antedicha complejidad, actualmente se habla de una Ingeniería[12] , aunque ella
aún no existe formalmente.
Hay grupos de estudio e investigación, en todo el mundo, que están
exclusivamente abocados a idear modelos, técnicas y procesos para intentar
lograr la correcta captura, análisis y registro de requisitos. Estos grupos son los
que normalmente hablan de la Ingeniería de requisitos; es decir se plantea ésta
como un área o disciplina pero no como una carrera universitaria en sí misma.
Algunos requisitos no necesitan la presencia del cliente, para ser capturados o
analizados; en ciertos casos los puede proponer el mismo analista o, incluso,
adoptar unilateralmente decisiones que considera adecuadas (tanto en requisitos
funcionales como no funcionales). Por citar ejemplos probables: Algunos
requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como
los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de
desarrollo, relaciones internas o ligas entre la información (entre registros o tablas
de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos
funcionales tales como opciones secundarias o de soporte necesarias para una
mejor o más sencilla operatividad; etc.
La obtención de especificaciones a partir del cliente (u otros actores
intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a
medida que se captura la información, se la analiza y realimenta con el cliente,
refinándola, puliéndola y corrigiendo si es necesario; cualquiera sea el método
de ERS utilizado. EL analista siempre debe llegar a conocer la temática y el
problema que resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro
sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad
para comprender problemas de muy diversas áreas o disciplinas de trabajo (que

26
no son específicamente suyas); así por ejemplo, si el sistema a desarrollar será
para gestionar información de una aseguradora y sus sucursales remotas, el
analista se debe compenetrar en cómo ella trabaja y maneja su información,
desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran
diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas,
es decir gente que conoce profundamente el área para la cual se desarrollará el
software; evidentemente una única persona (el analista) no puede abarcar tan
vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de
productos software, es común tener analistas especializados en ciertas áreas de
trabajo.
Contrariamente, no es problema del cliente, es decir él no tiene por qué saber
nada de software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar
a aportar objetivos, datos e información (de mano propia o de sus registros,
equipos, empleados, etc.) al analista, y guiado por él, para que, en primera
instancia, defina el «Universo de Discurso», y con posterior trabajo logre
confeccionar el adecuado documento ERS.
Es bien conocida la presión que sufren los desarrolladores de sistemas
informáticos para comprender y rescatar las necesidades de los clientes/usuarios.
Cuanto más complejo es el contexto del problema más difícil es lograrlo, a veces
se fuerza a los desarrolladores a tener que convertirse en casi expertos de los
dominios que analizan.
Cuando esto no sucede es muy probable que se genere un conjunto de
requisitos[13] erróneos o incompletos y por lo tanto un producto de software con
alto grado de desaprobación por parte de los clientes/usuarios y un altísimo costo
de reingeniería y mantenimiento. Todo aquello que no se detecte, o resulte mal
entendido en la etapa inicial provocará un fuerte impacto negativo en los
requisitos, propagando esta corriente degradante a lo largo de todo el proceso de
desarrollo e incrementando su perjuicio cuanto más tardía sea su
detección (Bell y Thayer 1976) (Davis 1993).

27
d.2.1.1. Procesos, modelado y formas de elicitación de requisitos
Siendo que la captura, elicitación y especificación de requisitos, es una parte
crucial en el proceso de desarrollo de software, ya que de esta etapa depende el
logro de los objetivos finales previstos, se han ideado modelos y diversas
metodologías de trabajo para estos fines. También existen herramientas software
que apoyan las tareas relativas realizadas por el ingeniero en requisitos.
El estándar IEEE 830-1998 brinda una normalización de las «Prácticas
Recomendadas para la Especificación de Requisitos Software».[14]
A medida que se obtienen los requisitos, normalmente se los va analizando, el
resultado de este análisis, con o sin el cliente, se plasma en un documento,
conocido como ERS o Especificación de Requisitos Software, cuya estructura
puede venir definida por varios estándares, tales como CMMI.
Un primer paso para realizar el relevamiento de información es el conocimiento y
definición acertada lo que se conoce como «Universo de Discurso» del problema,
que se define y entiende por:
Universo de Discurso (UdeD): es el contexto general en el cual el software
deberá ser desarrollado y deberá operar. El UdeD incluye todas las fuentes de
información y todas las personas relacionadas con el software. Esas personas
son conocidas también como actores de ese universo. El UdeD es la realidad
circunstanciada por el conjunto de objetivos definidos por quienes demandaron el
software.
A partir de la extracción y análisis de información en su ámbito se obtienen todas
las especificaciones necesarias y tipos de requisitos para el futuro producto
software.
El objetivo de la Ingeniería de requisitos (IR) es sistematizar el proceso de
definición de requisitos permitiendo elicitar, modelar y analizar el problema,
generando un compromiso entre los ingenieros de requisitos y los

28
clientes/usuarios, ya que ambos participan en la generación y definición de los
requisitos del sistema. La IR aporta un conjunto de métodos, técnicas y
herramientas que asisten a los ingenieros de requisitos (analistas) para obtener
requisitos lo más seguros, veraces, completos y oportunos posibles, permitiendo
básicamente:
 Comprender el problema
 Facilitar la obtención de las necesidades del cliente/usuario
 Validar con el cliente/usuario
 Garantizar las especificaciones de requisitos
Si bien existen diversas formas, modelos y metodologías para elicitar, definir y
documentar requisitos, no se puede decir que alguna de ellas sea mejor o peor
que la otra, suelen tener muchísimo en común, y todas cumplen el mismo
objetivo. Sin embargo, lo que sí se puede decir sin dudas es que es indispensable
utilizar alguna de ellas para documentar las especificaciones del futuro producto
software. Así por ejemplo, hay un grupo de investigación argentino que desde
hace varios años ha propuesto y estudia el uso del LEL (Léxico Extendido del
Lenguaje) y Escenarios como metodología, aquí[15] se presenta una de las tantas
referencias y bibliografía sobre ello. Otra forma, más ortodoxa, de capturar y
documentar requisitos se puede obtener en detalle, por ejemplo, en el trabajo de
la Universidad de Sevilla sobre «Metodología para el Análisis de Requisitos de
Sistemas Software».[16]
En la Figura 7 se muestra un esquema, más o menos riguroso, aunque no
detallado, de los pasos y tareas a seguir para realizar la captura, análisis y
especificación de requisitos software. También allí se observa qué artefacto o
documento se obtiene en cada etapa del proceso. En el diagrama no se explicita
metodología o modelo a utilizar, sencillamente se pautan las tareas que deben
cumplirse, de alguna manera.

29
Fig. 6 - Diagrama de tareas para captura y análisis de requisitos.
Una posible lista, general y ordenada, de tareas recomendadas para obtener la
definición de lo que se debe realizar, los productos a obtener y las técnicas a
emplear durante la actividad de elicitación de requisitos, en fase de Especificación
de Requisitos Software es:
1. Obtener información sobre el dominio del problema y el sistema actual
(UdeD).
2. Preparar y realizar las reuniones para elicitación/negociación.
3. Identificar/revisar los objetivos del usuario.
4. Identificar/revisar los objetivos del sistema.
5. Identificar/revisar los requisitos de información.
6. Identificar/revisar los requisitos funcionales.
7. Identificar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.
Algunos principios básicos a tener en cuenta:
 Presentar y entender cabalmente el dominio de la información del
problema.
 Definir correctamente las funciones que debe realizar el Software.

30
 Representar el comportamiento del software a consecuencias de
acontecimientos externos, particulares, incluso inesperados.
 Reconocer requisitos incompletos, ambiguos o contradictorios.
 Dividir claramente los modelos que representan la información, las
funciones y comportamiento y características no funcionales.
d.2.1.2. Clasificación e identificación de requisitos
Se pueden identificar dos formas de requisitos:
 Requisitos de usuario: Los requisitos de usuario son frases en lenguaje
natural junto a diagramas con los servicios que el sistema debe
proporcionar, así como las restricciones bajo las que debe operar.
 Requisitos de sistema: Los requisitos de sistema determinan los servicios
del sistema y pero con las restricciones en detalle. Sirven como contrato.
Es decir, ambos son lo mismo, pero con distinto nivel de detalle.
Ejemplo de requisito de usuario: El sistema debe hacer préstamos Ejemplo de
requisito de sistema: Función préstamo: entrada código socio, código ejemplar;
salida: fecha devolución; etc.
Se clasifican en tres los tipos de requisitos de sistema:
 Requisitos funcionales
Los requisitos funcionales describen:
 Los servicios que proporciona el sistema (funciones).
 La respuesta del sistema ante determinadas entradas.
 El comportamiento del sistema en situaciones particulares.

31
 Requisitos no funcionales
Los requisitos no funcionales son restricciones de los servicios o funciones que
ofrece el sistema (ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)
Ejemplo 1. La biblioteca Central debe ser capaz de atender
simultáneamente a todas las bibliotecas de la Universidad
Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser
superior a 1/2 s
A su vez, hay tres tipos de requisitos no funcionales:
 Requisitos del producto. Especifican el comportamiento del producto (Ej.
prestaciones, memoria, tasa de fallos, etc.)
 Requisitos organizativos. Se derivan de las políticas y procedimientos de
las organizaciones de los clientes y desarrolladores (Ej. estándares de
proceso, lenguajes de programación, etc.)
 Requisitos externos. Se derivan de factores externos al sistema y al
proceso de desarrollo (Ej. requisitos legislativos, éticos, etc.)
 Requisitos del dominio.
Los requisitos del dominio se derivan del dominio de la aplicación y reflejan
características de dicho dominio.
Pueden ser funcionales o no funcionales.
Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos
mediante el Lenguaje de Intercomunicación de Bibliotecas de España (LIBE). Ej.
El sistema de biblioteca no podrá acceder a bibliotecas con material censurado.
d.2.2. Diseño del sistema
En ingeniería de software, el diseño es una fase de ciclo de vida del software. Se
basa en la especificación de requisitos producido por el análisis de los requisitos

32
(fase de análisis), el diseño define cómo estos requisitos se cumplirán, la
estructura que debe darse al sistema de software para que se haga realidad.
El diseño sigue siendo una fase separada de la programación o codificación, esta
última corresponde a la traducción en un determinado lenguaje de
programación de las premisas adoptadas en el diseño.
Las distinciones entre las actividades mencionadas hasta ahora no siempre son
claras cómo se quisiera en las teorías clásicas de ingeniería de software. El
diseño, en particular, puede describir el funcionamiento interno de un sistema en
diferentes niveles de detalle, cada una de ellos se coloca en una posición
intermedia entre el análisis y codificación.
Normalmente se entiende por "diseño de la arquitectura" al diseño de "muy alto
nivel", que sólo define la estructura del sistema en términos de la módulos de
software de que se compone y las relaciones macroscópicas entre ellos. A este
nivel de diseño pertenecen fórmulas como cliente-servidor o “tres niveles”, o, más
generalmente, las decisiones sobre el uso de la arquitectura de hardware especial
que se utilice, el sistema operativo, DBMS, Protocolos de red, etc.
Un nivel intermedio de detalle puede definir la descomposición del sistema en
módulos, pero esta vez con una referencia más o menos explícita al modo de
descomposición que ofrece el particular lenguaje de programación con el que el
desarrollo se va a implementar, por ejemplo, en un diseño realizado con la
tecnología de objetos, el proyecto podría describir al sistema en términos
de clases y sus interrelaciones.
El diseño detallado, por último, es una descripción del sistema muy cercana a la
codificación (por ejemplo, describir no sólo las clases en abstracto, sino también
sus atributos y los métodos con sus tipos).
Debido a la naturaleza "intangible" del software, y dependiendo de las
herramientas que se utilizan en el proceso, la frontera entre el diseño y la
codificación también puede ser virtualmente imposible de identificar. Por ejemplo,

33
algunas herramientas CASE son capaces de generar código a partir de diagramas
UML, los que describen gráficamente la estructura de un sistema software.
d.2.3. Codificación del software
Es común pensar que la etapa de programación o codificación (algunos la llaman
implementación) es la que insume la mayor parte del trabajo de desarrollo del
software; sin embargo, esto puede ser relativo (y generalmente aplicable a
sistemas de pequeño porte) ya que las etapas previas son cruciales, críticas y
pueden llevar bastante más tiempo. Se suele hacer estimaciones de un 30% del
tiempo total insumido en la programación, pero esta cifra no es consistente ya que
depende en gran medida de las características del sistema, su criticidad y el
lenguaje de programación elegido.[7] En tanto menor es el nivel del lenguaje
mayor será el tiempo de programación requerido, así por ejemplo se tardaría más
tiempo en codificar un algoritmo en lenguaje ensamblador que el mismo
programado en lenguaje C.
Mientras se programa la aplicación, sistema, o software en general, se realizan
también tareas de depuración, esto es la labor de ir liberando al código de los
errores factibles de ser hallados en esta fase (de semántica, sintáctica y lógica).
Hay una suerte de solapamiento con la fase siguiente, ya que para depurar la
lógica es necesario realizar pruebas unitarias, normalmente con datos de prueba;
claro es que no todos los errores serán encontrados sólo en la etapa de
programación, habrán otros que se encontrarán durante las etapas subsiguientes.
La aparición de algún error funcional (mala respuesta a los requisitos)
eventualmente puede llevar a retornar a la fase de diseño antes de continuar la
codificación.
Durante la fase de programación, el código puede adoptar varios estados,
dependiendo de la forma de trabajo y del lenguaje elegido, a saber:
 Código fuente: es el escrito directamente por los programadores en
editores de texto, lo cual genera el programa. Contiene el conjunto de

34
instrucciones codificadas en algún lenguaje de alto nivel. Puede estar
distribuido en paquetes, procedimientos, bibliotecas fuente, etc.
 Código objeto: es el código binario o intermedio resultante de procesar con
un compilador el código fuente. Consiste en una traducción completa y
de una sola vez de éste último. El código objeto no es inteligible por el ser
humano (normalmente es formato binario) pero tampoco es directamente
ejecutable por la computadora. Se trata de una representación intermedia
entre el código fuente y el código ejecutable, a los fines de un enlace final
con las rutinas de biblioteca y entre procedimientos o bien para su uso con
un pequeño intérprete intermedio [a modo de distintos ejemplos
véase EUPHORIA, (intérprete intermedio), FORTRAN (compilador
puro) MSIL (Microsoft Interme diate Language) (intérprete)
y BASIC (intérprete puro, intérprete intermedio, compilador intermedio o
compilador puro, depende de la versión utilizada)].
o El código objeto no existe si el programador trabaja con un
lenguaje a modo de intérprete puro, en este caso el mismo
intérprete se encarga de traducir y ejecutar línea por línea el código
fuente (de acuerdo al flujo del programa), en tiempo de ejecución.
En este caso tampoco existe el o los archivos de código ejecutable.
Una desventaja de esta modalidad es que la ejecución del programa
o sistema es un poco más lenta que si se hiciera con un intérprete
intermedio, y bastante más lenta que si existe el o los archivos de
código ejecutable. Es decir no favorece el rendimiento en velocidad
de ejecución. Pero una gran ventaja de la modalidad intérprete puro,
es que el esta forma de trabajo facilita enormemente la tarea de
depuración del código fuente (frente a la alternativa de hacerlo con
un compilador puro). Frecuentemente se suele usar una forma mixta
de trabajo (si el lenguaje de programación elegido lo permite), es
decir inicialmente trabajar a modo de intérprete puro, y una vez
depurado el código fuente (liberado de errores) se utiliza un
compilador del mismo lenguaje para obtener el código ejecutable

35
completo, con lo cual se agiliza la depuración y la velocidad de
ejecución se optimiza.
 Código ejecutable: Es el código binario resultado de enlazar uno o más
fragmentos de código objeto con las rutinas y bibliotecas necesarias.
Constituye uno o más archivos binarios con un formato tal que el sistema
operativo es capaz de cargarlo en la memoria RAM (eventualmente
también parte en una memoria virtual), y proceder a su ejecución directa.
Por lo anterior se dice que el código ejecutable es directamente «inteligible
por la computadora». El código ejecutable, también conocido como código
máquina, no existe si se programa con modalidad de «intérprete puro».
d.2.4. Pruebas (unitarias y de integración)
Entre las diversas pruebas que se le efectúan al software se pueden distinguir
principalmente:
 Prueba unitarias: Consisten en probar o testear piezas de software
pequeñas; a nivel de secciones, procedimientos, funciones y módulos;
aquellas que tengan funcionalidades específicas. Dichas pruebas se
utilizan para asegurar el correcto funcionamiento de secciones de código,
mucho más reducidas que el conjunto, y que tienen funciones concretas
con cierto grado de independencia.
 Pruebas de integración: Se realizan una vez que las pruebas unitarias
fueron concluidas exitosamente; con éstas se intenta asegurar que el
sistema completo, incluso los subsistemas que componen las piezas
individuales grandes del software funcionen correctamente al operar e
interoperar en conjunto.
Las pruebas normalmente se efectúan con los llamados datos de prueba, que es
un conjunto seleccionado de datos típicos a los que puede verse sometido el
sistema, los módulos o los bloques de código. También se escogen: Datos que
llevan a condiciones límites al software a fin de probar su tolerancia y robustez;

36
datos de utilidad para mediciones de rendimiento; datos que provocan
condiciones eventuales o particulares poco comunes y a las que el software
normalmente no estará sometido pero pueden ocurrir; etc. Los «datos de prueba»
no necesariamente son ficticios o «creados», pero normalmente sí lo son los de
poca probabilidad de ocurrencia.
Generalmente, existe una fase probatoria final y completa del software,
llamada Beta Test, durante la cual el sistema instalado en condiciones normales
de operación y trabajo es probado exhaustivamente a fin de encontrar errores,
inestabilidades, respuestas erróneas, etc. que hayan pasado los previos
controles. Estas son normalmente realizadas por personal idóneo contratado o
afectado específicamente a ello. Los posibles errores encontrados se transmiten a
los desarrolladores para su depuración. En el caso de software de desarrollo «a
pedido», el usuario final (cliente) es el que realiza el Beta Test, teniendo para ello
un período de prueba pactado con el desarrollador.
d.2.5. Instalación y paso a producción
La instalación del software es el proceso por el cual los programas desarrollados
son transferidos apropiadamente al computador destino, inicializados, y,
eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el
usuario final. Constituye la etapa final en el desarrollo propiamente dicho del
software. Luego de ésta el producto entrará en la fase de funcionamiento y
producción, para el que fuera diseñado.
La instalación, dependiendo del sistema desarrollado, puede consistir en una
simple copia al disco rígido destino (casos raros actualmente); o bien, más
comúnmente, con una de complejidad intermedia en la que los distintos archivos
componentes del software (ejecutables, bibliotecas, datos propios, etc.)
son descomprimidos y copiados a lugares específicos preestablecidos del disco;
incluso se crean vínculos con otros productos, además del propio sistema
operativo. Este último caso, comúnmente es un proceso bastante automático que

37
es creado y guiado con herramientas software específicas (empaquetado y
distribución, instaladores).
En productos de mayor complejidad, la segunda alternativa es la utilizada, pero es
realizada o guiada por especialistas; puede incluso requerirse la instalación en
varios y distintos computadores (instalación distribuida).
También, en software de mediana y alta complejidad normalmente es requerido
un proceso de configuración y chequeo, por el cual se asignan adecuados
parámetros de funcionamiento y se testea la operatividad funcional del producto.
En productos de venta masiva las instalaciones completas, si son relativamente
simples, suelen ser realizadas por los propios usuarios finales (tales como
sistemas operativos, paquetes de oficina, utilitarios, etc.) con herramientas
propias de instalación guiada; incluso la configuración suele ser automática. En
productos de diseño específico o «a medida» la instalación queda restringida,
normalmente, a personas especialistas involucradas en el desarrollo del software
en cuestión.
Una vez realizada exitosamente la instalación del software, el mismo pasa a la
fase de producción (operatividad), durante la cual cumple las funciones para las
que fue desarrollado, es decir, es finalmente utilizado por el (o los) usuario final,
produciendo los resultados esperados.
d.2.6. Mantenimiento
El mantenimiento de software es el proceso de control, mejora y optimización del
software ya desarrollado e instalado, que también incluye depuración de errores y
defectos que puedan haberse filtrado de la fase de pruebas de control y beta test.
Esta fase es la última (antes de iterar, según el modelo empleado) que se aplica
al ciclo de vida del desarrollo de software. La fase de mantenimiento es la que
viene después de que el software está operativo y en producción.

38
De un buen diseño y documentación del desarrollo dependerá cómo será la fase
de mantenimiento, tanto en costo temporal como monetario. Modificaciones
realizadas a un software que fue elaborado con una documentación indebida o
pobre y mal diseño puede llegar a ser tanto o más costosa que desarrollar el
software desde el inicio. Por ello, es de fundamental importancia respetar
debidamente todas las tareas de las fases del desarrollo y mantener adecuada y
completa la documentación.
El período de la fase de mantenimiento es normalmente el mayor en todo el ciclo
de vida.[7] Esta fase involucra también actualizaciones y evoluciones del software;
no necesariamente implica que el sistema tuvo errores. Uno o más cambios en el
software, por ejemplo de adaptación o evolutivos, puede llevar incluso a rever y
adaptar desde parte de las primeras fases del desarrollo inicial, alterando todas
las demás; dependiendo de cuán profundos sean los cambios. El modelo cascada
común es particularmente costoso en mantenimiento, ya que su rigidez implica
que cualquier cambio provoca regreso a fase inicial y fuertes alteraciones en las
demás fases del ciclo de vida.
Durante el período de mantenimiento, es común que surjan nuevas revisiones y
versiones del producto; que lo liberan más depurado, con mayor y mejor
funcionalidad, mejor rendimiento, etc. Varias son las facetas que pueden ser
alteradas para provocar cambios deseables, evolutivos, adaptaciones o
ampliaciones y mejoras.
Básicamente se tienen los siguientes tipos de cambios:
 Perfectivos: Aquellos que llevan a una mejora de la calidad interna del
software en cualquier aspecto: Reestructuración del código, definición más
clara del sistema y su documentación; optimización del rendimiento y
eficiencia.
 Evolutivos: Agregados, modificaciones, incluso eliminaciones, necesarias
en el software para cubrir su expansión o cambio, según las necesidades
del usuario.

39
 Adaptivos: Modificaciones que afectan a los entornos en los que el sistema
opera, tales como: Cambios de configuración del hardware (por
actualización o mejora de componentes electrónicos), cambios en el
software de base, en gestores de base de datos, en comunicaciones, etc.
 Correctivos: Alteraciones necesarias para corregir errores de cualquier tipo
en el producto software desarrollado.
e. Carácter evolutivo del software[17]
El software es el producto derivado del proceso de desarrollo, según la ingeniería
de software. Este producto es intrínsecamente evolutivo durante su ciclo de vida.
El software evoluciona, en general, generando versiones cada vez más
completas, complejas, mejoradas, optimizadas en algún aspecto, adecuadas a
nuevas plataformas (sean de hardware o sistemas operativos), etc.
Cuando un sistema deja de evolucionar, eventualmente cumplirá con su ciclo de
vida, entrará en obsolescencia e inevitablemente, tarde o temprano, será
reemplazado por un producto nuevo.
El software evoluciona sencillamente porque se debe adaptar a los cambios del
entorno, sean funcionales (exigencias de usuarios), operativos, de plataforma o
arquitectura hardware.
La dinámica de evolución del software es el estudio de los cambios del sistema.
La mayor contribución en esta área fue realizada por Meir M. Lehman y Belady,
comenzando en los años 70 y 80. Su trabajo continuó en la década de 1990, con
Lehman y otros investigadores[18] de relevancia en la realimentación en los
procesos de evolución (Lehman, 1996; Lehman et al., 1998; lehman et al., 2001).
A partir de esos estudios propusieron un conjunto de leyes (conocidas como leyes
de Lehman)[9] respecto de los cambios producidos en los sistemas. Estas leyes
(en realidad son hipótesis) son invariantes y ampliamente aplicables.

40
Lehman y Belady analizaron el crecimiento y la evolución de varios sistemas
software de gran porte; derivando finalmente, según sus medidas, las siguientes
ocho leyes:
1. Cambio continuo: Un programa que se usa en un entorno real
necesariamente debe cambiar o se volverá progresivamente menos útil en
ese entorno.
2. Complejidad creciente: A medida que un programa en evolución cambia, su
estructura tiende a ser cada vez más compleja. Se deben dedicar recursos
extras para preservar y simplificar la estructura.
3. Evolución prolongada del programa: La evolución de los programas es un
proceso autorregulativo. Los atributos de los sistemas, tales como tamaño,
tiempo entre entregas y la cantidad de errores documentados son
aproximadamente invariantes para cada entrega del sistema.
4. Estabilidad organizacional: Durante el tiempo de vida de un programa, su
velocidad de desarrollo es aproximadamente constante e independiente de
los recursos dedicados al desarrollo del sistema.
5. Conservación de la familiaridad: Durante el tiempo de vida de un sistema,
el cambio incremental en cada entrega es aproximadamente constante.
6. Crecimiento continuado: La funcionalidad ofrecida por los sistemas tiene
que crecer continuamente para mantener la satisfacción de los usuarios.
7. Decremento de la calidad: La calidad de los sistemas software comenzará
a disminuir a menos que dichos sistemas se adapten a los cambios de su
entorno de funcionamiento.
8. Realimentación del sistema: Los procesos de evolución incorporan
sistemas de realimentación multiagente y multibucle y estos deben ser
tratados como sistemas de realimentación para lograr una mejora
significativa del producto.

41
V. MATERIALES Y MÉTODOS
5.1. Lugar y fecha de ejecución
La presente práctica Pre-Profesional se realizó en el Centro de Innovación y
Emprendimiento Agroindustrial, perteneciente a la Escuela Académico
profesional de Ingeniería Agroindustrial de la Universidad Nacional “Hermilio
Valdizán”, que está ubicado en la avenida Universitaria N° 601-607, Pabellón
Ciencias Agrarias, primer piso; la práctica se realizó desde el 05 de enero al
05 de abril del 2015.
5.2. Materiales y equipos
5.2.1. Materiales
5.2.1.1. Lapiceros
5.2.1.2. Cuadernos
5.2.1.3. Plumones
5.2.1.4. DVD’S
5.2.1.5. Hojas de bond
5.2.1.6. USB’S
5.2.2. Equipos
5.2.2.1. Computadora
5.2.2.2. Impresora
5.2.2.3. Parlante
5.2.2.4. Teléfono
5.3. Conducción de las prácticas pre-profesionales
El desarrollo del software comprende varias atapas, y cada una de estas etapas
tienen que ser estrictamente analizadas, para el desarrollo del software hemos
tenido que trabajar los algoritmos basado en los procesos agroindustriales, y el
orden ha sido según el producto a elaborar, por ejemplo en primer orden se ha

42
puesto el producto a elaborar, procediendo por el segundo orden este que a su
vez está en varias etapas; segundo orden (primero): formulación para el producto
a elaborar, segundo orden (segundo) diagrama de flujo del producto a elaborar,
segundo orden (tercero) descripción del proceso, segundo orden (cuarto) control
de calidad y otros aspectos, y por último en el tercer orden se ha considerado los
aplicativos integrados al proceso productivo de la elaboración del determinado
producto, y todo esto pertenece al área “B”, porque esta área pertenece a los
procesos agroindustriales, para mayor detalle del área de desarrollo a
continuación se muestran los diagramas de desarrollo.
Diagrama de desarrollo Nº 1: ÁREAS DE DESARROLLO DEL SOFTWARE:
Para cada uno de estas áreas existen sub áreas a lo cual la hemos denominado
en órdenes, estos órdenes es de acuerdo al avance del desarrollo del software, y
lo mostramos a continuación:
Área “A” Área “B” Área “C”
ÁREAS DE DESARROLLO
En esta área se ha
integrado el desarrollo
de aplicativos de
ingeniería, para
realizar diferentes
cálculos matemáticos
de manera general, y
otros cálculos
relacionados con el
campo agroindustrial.
En esta área se ha
de aplicativos
relacionados con los
procesos
agroindustriales,
aunque en si este es el
área a lo cual más está
enfocado el desarrollo
de este software.
En esta área se ha
de aplicativos
relacionados con la
parte de gestión y
administración a partir
de los sistemas
integrados en el
software.
PROGRAMACIÓN

43
Diagrama de desarrollo Nº 2: ÓRDENES DE DESARROLLO DEL SOFTWARE:
Diagrama de desarrollo Nº 2.1.: ÓRDENES DE DESARROLLO DEL
SOFTWARE EN EL ÁREA “A”:
Los tres órdenes de desarrollo en el área “A”, está basado básicamente en el
desarrollo de sistemas integrados codificados en tres órdenes como se
muestra en la figura de desarrollo N° 2.1.; donde en cada uno se establecido
los algoritmos correspondientes, y cada una de estas con diferentes
funciones para formar un sistema integrado de algoritmos para resolver,
PRIMER ORDEN SEGUNDO
ORDEN
TERCER ORDEN
ÓRDENES DE DESARROLLO
INTEGRACIÓN
ORDEN
TERCER ORDEN
ÓRDENES DE DESARROLLO EN EL ÁREA “A”
CODIFICACIÓN
Se considera como
primer orden los
sistemas integrados,
para el procesamiento
y análisis de diferentes
tipos de datos.
Elaboración y
formulación de
algoritmos en
secuencias.
Integración de módulo
en el sistema de
algoritmos, para la
fluidez en el
procesamiento.

44
procesar, analizar y desplegar cualquier dato solicitado por el usuario; si se
le solicitan algún dato que no ha sido integrado dentro de la codificación,
está controlado la parte de excepciones, donde el propio software
responderá al usuario que dicha solicitud no procederá y deberá de
reformular la solicitud de acuerdo a los estándares del sistema integrado del
propio software.

45
SOFTWARE EN EL ÁREA “B”:
En esta área la codificación ha sido realizada basándonos en los procesos, para
lo cual se ha solicitado la ayuda de expertos en el tema de procesamiento de
productos agroindustriales y también hemos recurrido a diversas fuentes
bibliográficas para el respectivo soporte que se le ha dado; gracias a todos esos
aportes se ha podido formular los algoritmos necesarios para la integración y
codificación en esta área.
ORDEN
TERCER ORDEN
ÓRDENES DE DESARROLLO EN EL ÁREA “B”
CODIFICACIÓN
El primer orden es la
elección del producto a
elaborar, los algoritmos
del primer orden son
los algoritmos que
actúan como centro o
eje de la programación
del área “B”, porque de
aquí se parte al
producto que uno
desea elaborar, porque
no se puede ir al
segundo orden sin
pasar por este primer
orden.
Aquí consideramos
barios subórdenes:
Para este orden hemos
considerado, los
aplicativos secundarios
que le dan más vida al
software, como es
interacción de la
presentación, otro de
los aspectos es la
emisión de la voz,
emitido por el mismo
sistema, con la previa
orden del lenguaje de
programación usado.
PRIMERO:
Formulación
SEGUNDO: Diagrama
de flujo
TERCERO:
Descripción del
proceso

46
SOFTWARE EN EL ÁREA “C”:
Los diagramas de desarrollo mostrados, pueden ser tan sencillos como
también pueden ser tan complejos para su explicación, en aquí hemos
mostrado diagramas simples para entender de manera fácil toda la
programación que se ha realizado para el desarrollo del software, cabe
mencionar que estos diagramas pudieron haber sido estructurados de
manera más compleja.
ORDEN
TERCER ORDEN
ÓRDENES DE DESARROLLO EN EL ÁREA “B”
CODIFICACIÓN
En esta parte los tres órdenes de desarrollo se pueden trabajar paralelamente y
de la misma manera, es decir la formulación de algoritmos es lo mismo para
cualquier dato que se va a procesar, es por ello que todo gira en base a la
misma formulación.

47
Diagrama de desarrollo Nº 3: IMPLEMENTACIÓN GRÁFICA
El diseño gráfico siempre va de la mano con la codificación, esta puede ser de
manera directa o indirecta, es decir el diseño gráfico puede ser generado por los
propios códigos de diseño, tal como se ha realizado en el presente software,
donde todo el diseño es auténtico y original propio del diseño del mismo
programador.
DISEÑO DE
INTERFAZ GRÁFICA
ÁREA “A”
CODIFICACIÓN E IMPLEMENTACIÓN GRÁFICA
ÁREA “B”
ÁREA “C”
ALIMENTACIÓN
P
R
O
G
R
A
M
A
C
I
Ó
N

48
El proceso de desarrollo puede involucrar numerosas y variadas tareas,[6] desde lo
administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento.
Pero, casi rigurosamente, siempre se cumplen ciertas etapas mínimas; las que se
pueden resumir como sigue:
Diagrama de desarrollo Nº 4: Diagrama de flujo de desarrollo del software
A. Diagrama de flujo general para el desarrollo del software Agroindustrial.
Diagrama de desarrollo Nº 4: Diagrama de flujo de desarrollo del software
B. Diagrama de flujo específico para el desarrollo del software.
CAPTURA, ELICITACIÓN, ESPECIFICACIÓN
Y ANÁLISIS DE REQUISITOS (ERS)
DISEÑO
CODIFICACIÓN
PRUEBAS (UNITARIAS Y DE INTEGRACIÓN)
INSTALACIÓN Y PASO A PRODUCCIÓN
PROCESOPARAEL
DESARROLLODESOFTWARE
AGROINDUSTRIAL
RETROALIMENTACIÓN
MANTENIMIENTO
DEFINICIÓN DE REQUERIMIENTOS
ANÁLISIS Y DISEÑO DEL SOFTWARE
IMPLEMENTACIÓN Y PRUEBA DE ANÁLISIS
INTEGRACIÓN Y PRUEBA DEL SISTEMA
OPERACIÓN Y MANTENIMIENTO
PROCESOPARAEL
DESARROLLODESOFTWARE
AGROINDUSTRIAL
RETROALIMENTACIÓN

49
En las anteriores etapas pueden variar ligeramente sus nombres, o ser más
globales, o contrariamente, ser más refinadas; por ejemplo indicar como una
única fase (a los fines documentales e interpretativos) de «análisis y diseño»; o
indicar como «implementación» lo que está dicho como «codificación»; pero en
rigor, todas existen e incluyen, básicamente, las mismas tareas específicas.
Descripción de las etapas del diagrama de flujo “proceso de creación del
software”
5.3.1. Definición de requerimientos
En esta etapa básicamente se define el proyecto a realizarse y todo lo necesario
que vamos a utilizar para hacer realidad el programa.
En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y
especifican las características funcionales y no funcionales que deberá cumplir el
futuro programa o sistema a desarrollar.
El estándar IEEE 830-1998 brinda una normalización de las «Prácticas
Recomendadas para la Especificación de Requisitos Software».
Las bondades de las características, tanto del sistema o programa a desarrollar,
como de su entorno, parámetros no funcionales y arquitectura dependen
enormemente de lo bien lograda que esté esta etapa. Esta es, probablemente, la
de mayor importancia y una de las fases más difíciles de lograr certeramente,
pues no es automatizable, no es muy técnica y depende en gran medida de la
habilidad y experiencia del analista que la realice.
5.3.2. Análisis y diseño del software
Este es una tarea donde se realiza un análisis para el desarrollo de software
como por ejemplo analizamos de donde se van a extraer los datos para la
formulación de los algoritmos, también analizamos la parte grafica que va tener el
software.
En ingeniería de software, el diseño es una fase de ciclo de vida del software. Se
basa en la especificación de requisitos producido por el análisis de los requisitos

50
(fase de análisis), el diseño define cómo estos requisitos se cumplirán, la
estructura que debe darse al sistema de software para que se haga realidad.
El diseño sigue siendo una fase separada de la programación o codificación, esta
última corresponde a la traducción en un determinado lenguaje de programación
de las premisas adoptadas en el diseño.
5.3.3. Codificación del software
Durante esta etapa se realizan las tareas que comúnmente se conocen
como programación; que consiste, esencialmente, en llevar a código fuente, en el
lenguaje de programación elegido, todo lo diseñado en la fase anterior. Esta tarea
la realiza el programador, siguiendo por completo los lineamientos impuestos en
el diseño y en consideración siempre a los requisitos funcionales y no funcionales
(ERS) especificados en la primera etapa.
Mientras se programa la aplicación, sistema, o software en general, se realizan
también tareas de depuración, esto es la labor de ir liberando al código de los
errores factibles de ser hallados en esta fase (de semántica, sintáctica y lógica).
Hay una suerte de solapamiento con la fase siguiente, ya que para depurar la
lógica es necesario realizar pruebas unitarias, normalmente con datos de prueba;
claro es que no todos los errores serán encontrados sólo en la etapa de
programación, habrán otros que se encontrarán durante las etapas subsiguientes.
La aparición de algún error funcional (mala respuesta a los requisitos)
eventualmente puede llevar a retornar a la fase de diseño antes de continuar la
codificación
5.3.4. Integración y prueba del sistema
Entre las diversas pruebas que se le efectúan al software se pueden distinguir
principalmente:
 Prueba unitarias: Consisten en probar o testear piezas de software
pequeñas; a nivel de secciones, procedimientos, funciones y módulos;
aquellas que tengan funcionalidades específicas. Dichas pruebas se

51
utilizan para asegurar el correcto funcionamiento de secciones de código,
mucho más reducidas que el conjunto, y que tienen funciones concretas
con cierto grado de independencia.
 Pruebas de integración: Se realizan una vez que las pruebas unitarias
fueron concluidas exitosamente; con éstas se intenta asegurar que el
sistema completo, incluso los subsistemas que componen las piezas
individuales grandes del software funcionen correctamente al operar e
interoperar en conjunto.
5.3.5. Instalación y paso a producción
La instalación del software es el proceso por el cual los programas desarrollados
son transferidos apropiadamente al computador destino, inicializados, y,
eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el
usuario final. Constituye la etapa final en el desarrollo propiamente dicho del
software. Luego de ésta el producto entrará en la fase de funcionamiento y
producción, para el que fuera diseñado.
5.3.6. Operación y mantenimiento
El mantenimiento de software es el proceso de control, mejora y optimización del
software ya desarrollado e instalado, que también incluye depuración de errores y
defectos que puedan haberse filtrado de la fase de pruebas de control y beta test.
Esta fase es la última (antes de iterar, según el modelo empleado) que se aplica
al ciclo de vida del desarrollo de software. La fase de mantenimiento es la que
viene después de que el software está operativo y en producción.

52
VI. RESULTADOS
Después de estar día tras día golpeando el teclado frente a un monitor,
pasando más de 12 horas diarias con los ojos prendidos en las líneas de
escritura de códigos que son sentenciados y depurados en miles de líneas
de códigos; de tanto estar sentado sobre un sillón ya no sentía el cuerpo
físico reclinado sobre la silla, más bien sentía estar en un nuevo mundo
donde lo único que existía era yo y la computadora, entonces como éramos
solo los dos teníamos que llevarnos muy bien, pero el gran problema era
que yo tenía un lenguaje muy distinto a la de la computadora, eso asía que
no podíamos comunicarnos fluidamente, por lo que tuve que recurrir al
estudio del lenguaje adecuado para armonizar un buen ambiente entre
ambos, no fue tan fácil lograr realizar esa conexión entre ambos, pues mis
deseos solicitados no eran atendidos por la computadora, por lo que poco
a poco me di dando cuenta de que para comunicarnos yo debía formular
de manera correcta mis deseos a través del lenguaje que estábamos
usando ambos, entendí que con la computadora no podía bromear, así que
tome el trabajo el serio y dentro de poco tiempo me di cuenta que éramos
grandes amigos (entonces recién podíamos bromear), también ya podía
formular algoritmos que las enviaba y que me recibía con mucho gusto, la
procesaba y me preguntaba qué es lo que quería hacer con el algoritmo
que yo le cargaba, entonces allí recién me di cuenta que ya era un
programador de un nivel lógico (pero seguíamos siendo grandes amigos),
fue así que cada día me iba acostumbrando más y más en ese mundo
llenos do códigos, algoritmos, sentencias, etc., entonces ya podía hablar de
desarrollo de software, pero mencionar la frase: desarrollo de software
agroindustrial, no cabía dentro de los estándares, por lo que teníamos que
definir como: desarrollo de software, como todo proyecto de esta área
teníamos que realizarlo siguiendo los estándares y las reglas de trabajo,
por lo que cumplir con todas esa series de normas nos permitió realizar un
producto de calidad que cumpla ciertos requisitos y que tenía que pasar
por un control de calidad (por el momento no se ha realizado el control de
calidad, cabe destacar que dentro de un breve tiempo esto será realidad); y

53
todos los datos alimentados a la secuencia de algoritmos son propios de
los procesos agroindustriales, igualmente se ha recolectado datos de
diferentes libros, por lo que al final terminaron hechos en códigos y
procesados por mi ya conocido amigo; el producto obtenido hasta el
momento no está preparado aun para salir a un mercado donde existen
gigantes empresas que ofertan softwares de muchísima mejor calidad, por
lo que estamos haciendo todo lo posible para que este producto tenga un
lugar en el mercado y podamos competir con los verdaderos monstruos de
la programación.
Durante los tres meses de las prácticas pre-profesionales, se ha
desarrollado muchísima secuencia de códigos, integración de sistemas
para proceso, análisis y verificación de datos, diseño de la interfaz gráfica,
integración de sensores digitales grabados en el software, automatización
de los sistemas integrados a nivel de software, estructuramiento de la
arquitectura del software y otros detalles que le dan un estilo propio y
“ORIGINAL” al software; nos comprometemos en seguir corriendo esta
gran maratón soportando el inmenso peso de los códigos, y llegar a la
meta donde nos espera un Software de Alta Calidad.
VII. DISCUSIÓN
Desarrollar un software no es una tarea fácil, requiere de un gran
compromiso y de una inmensa pasión por la programación, no solo eso,
también requiere de muchísimo razonamiento, y junto a ello estar
físicamente en las mejores condiciones, de no ser así el producto final no
será como lo esperamos.
Desarrollar un software significa construirlo simplemente mediante su
descripción. Está es una muy buena razón para considerar la actividad de
desarrollo de software como una ingeniería. En un nivel más general, la

54
relación existente entre un software y su entorno es clara ya que el software
es introducido en el mundo de modo de provocar ciertos efectos en el
mismo.
Aquellas partes del mundo que afectarán al software y que serán afectadas
por él será el Dominio de Aplicación. Es allí donde los usuarios o clientes
observarán si el desarrollo del software ha cumplido su propósito.
Una de las mayores deficiencias en la práctica de construcción de software
es la poca atención que se presta a la discusión del problema. En general los
desarrolladores se centran en la solución dejando el problema inexplorado.
El problema a resolver debe ser deducido a partir de su solución.
Esta aproximación orientada a la solución puede funcionar en campos donde
todos los problemas son bien conocidos, clasificados e investigados, donde
la innovación se ve en la detección de nuevas soluciones a viejos problemas.
Pero el desarrollo de software no es un campo con tales características. La
versatilidad de las computadoras y su rápida evolución hace que exista un
repertorio de problemas en constante cambio y cuya solución software sea
de enorme importancia.
Actualmente la transición que estamos viviendo hacia una sociedad del
conocimiento ha cambiado profundamente las relaciones entre las personas,
empresas y gobiernos: las empresas usan la red para comunicarse con los
clientes, utilizan también herramientas de gestión del conocimiento para
hacer más eficientes, los gobiernos mejoran su presencia en Internet y los
servicios a los ciudadanos a través de la red, los usuarios usan las
herramientas para sus relaciones personales, etc. Se va de forma imparable
hacia una sociedad altamente interconectada donde el eje fundamental es la
información.
El software es el intermediario cada vez más grande entre la información y la
inteligencia humana. De la misma manera que preocupa para poder acceder
a la información, si existe la censura, es tema de preocupación de quien
controla este intermediario y las garantías de su transparencia y
confiabilidad.

55
En principio, el software es un programa informático o conjunto de ellos que
tiene un fin determinado, es el de procesar los textos que usamos, el
controlador de grabación de nuestros espacios favoritos o las aplicaciones
que permiten operar un teléfono móvil.
Está compuesto por un conjunto de instrucciones que el usuario realiza para
ejecutar una función específica. Normalmente los programadores escriben
en un lenguaje en el que todos pueden entender y que después es traducido
al lenguaje binario el único que las maquinas entienden. El conjunto de
órdenes en el lenguaje que todos trabajan se llaman código fuente.

56
VIII. CONCLUSIÓN
El desarrollo del software permite mejorar, controlar y monitorear los
procesos agroindustriales, afirmación que se puede contrastar con el uso
del software, para lo cual ya está disponible a nivel aplicación simple,
seguimos trabajando, para convertir esto al nivel de software, con todas
sus componentes, dentro de ello el más importante es el Setup Wizard
(aplicación de instalación), pero cabe destacar que para realizar las
pruebas de funcionamiento es suficiente con el nivel aplicativo, cosa que
nos lleva a una conclusión bastante clara y predecible con la diversidad de
pruebas que se realizó dentro del Laboratorio de Innovación y
Emprendimiento Agroindustrial, de la misma manera nos hemos
desplazado al Laboratorio de Procesos para monitorear y controlar los
procesos agroindustriales, valga la sinceridad que aún tenemos mucho que
mejorar para el verdadero control y monitoreo de los procesos, pero lo
obtenido hasta el momento es lo suficiente como para realizar los procesos
agroindustriales.
El software desarrollado permite el mejoramiento de los procesos
agroindustriales, debido a los sistemas integrados que se ha incorporado al
sistema, esto permite una buena interacción entre el usuario y el programa,
por lo que el usuario tendrá todo lo necesario a su alcance, con tan solo dar
un clic se podrá desplegar una gama de información que será usada para
el determinado proceso productivo.
El software desarrollado permite incrementar la productividad dentro de las
empresas, este incremento de la productividad aunque no sea a gran
escala por el momento debido a la falta de implementación del software
como los equipos con todos los sensores integrados, pero por ahora
podríamos mencionar de la gran facilidad de cálculo, el acceso a la
información esto de alguna manera menora los costos de producción.

57
El software desarrollado cuenta con sistemas de cálculos integrados, esto
permite ingresar, procesar y desplegar diferentes tipos de datos, ya sean
matemáticos, estadísticos u otros, pero el reto aún no ha terminado, se
está trabajando para seguir integrando una diversidad de cálculos de la
ingeniería, lo cual hará que el programa sea más dinámico y más fluido,
eso aumenta la posibilidad de que sea usado por las diferentes áreas de la
ciencia de la ingeniería.
IX. RECOMENDACIÓN
Actualmente en nuestra región se carece de información orientado a la
programación y desarrollo de software, recomendamos a todas las
autoridades políticas y educativas tomar conciencia acerca de este tema,
porque es una manera de salir del círculo vicioso, en nuestro caso el de la
agroindustria hay que romper esquemas y alterar sílabos de algunos cursos,
con el único fin de abrir un camino hacia el verdadero conocimiento, para de
esa manera dejar de ser una rama dependiente de otras ciencias y de otros
países, seamos nosotros mismos los productores de tecnología, por qué no
hacerlo?, hasta cuándo vamos a seguir comprando las tecnologías de
otros?, comencemos con lo poco que podemos, hagamos un poco más de
esfuerzo para ir más allá de lo normal, será difícil de lograrlo pero no
imposible.

58
X. LITERATURA CITADA
a. Libros
 Fowler, Martin; Kendall Sccott (1999). UMLGota a Gota. Addison
Wesley. ISBN 9789684443648.
 Gottesdiener, Ellen; P. Sawyer (2002). Requirements by Collaboration:
Workshops for Defining Needs (en inglés). Addison-Wesley Professional.
pp. 368 p. ISBN 978-0201786064.
 Haeberer, A. M.; P. A. S. Veloso, G. Baum (1988). Formalización del
proceso de desarrollo de software (Ed. preliminar edición). Buenos Aires:
Kapelusz. ISBN 950-13-9880-3.
 JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). El
Proceso Unificado de Desarrollo de Software. Pearson Addisson-Wesley.
 JACOBSON; BOOCH; RUMBAUGH (1999). UML - El Lenguaje Unificado
de Modelado. Pearson Addisson-Wesley. Rational Software Corporation,
Addison Wesley Iberoamericana. ISBN 84-7829-028-1.
 Loucopoulos, Pericles; Karakostas, V. (1995). System Requirements
Engineering (en inglés). London: McGraw-Hill Companies. pp. 160
p. ISBN 978-0077078430.
 Pressman, Roger S. (2003). Ingeniería del Software, un enfoque
Práctico (Quinta edición edición). Mc Graw Hill. ISBN 84-481-3214-9.
 Sommerville, Ian (2005). Ingeniería del software (7ma. edición). Madrid:
Pearson Educación S.A. ISBN 84-7829-074-5.
 Sommerville, Ian; P. Sawyer (1997). Requirements Engineering: A Good
Practice Guide (en inglés) (1ra. edition edición). Wiley&Sons. pp. 404
p. ISBN 978-0471974444.

59
b. Artículos y revistas
 «Software Requirements Engineering», 2nd Edition, IEEE Computer
Society. Los Alamitos, CA, 1997 (Compendio de papers y artículos en
ingeniería de requisitos).
 Carlos Reynoso - «Métodos Heterodoxos en Desarrollo de Software» -
2004
 Cutter IT Journal – «Requirements Engineering and Management». August
25, 2000. CutterConsortium.
 Grupo ISSI - Univ. Politécnica de Valencia - «Metodologías Ágiles en el
Desarrollo de Software» - 2003
 Lehman, M.M. - «Laws of Software Evolution Revisited», pos. pap.,
EWSPT96, Oct. 1996, LNCS 1149, Springer Verlag, 1997, pp. 108-124
 Martin Fowler - «La Nueva Metodología» - 2003
 Weitzenfeld - «El Proceso para Desarrollo de Software» - 2002

60
XI. ANEXOS
ANEXO Nº 1: Referencias del marco teórico
1. «ACM Fellow Profile for Meir M. (Manny) Lehman». ACM (31 de mayo de
2007). Consultado el 27 de noviembre de 2011.
2. «Ciclo de vida del Software y Modelos de desarrollo». Instituto de
Formación Profesional - Libros Digitales.
3. «Ciclo de Vida del Software». Grupo Alarcos - Escuela Superior de
Informática de Ciudad Real.
4. «Evolución del Software». Connexions - Educationalcontentrepository.
5. «III Workshop de Engenharia de Requisitos». WER 2000, Rio de Janeiro,
2000..
6. «LEL y Escenarios como metodología en Ingeniería de Requisitos». Univ.
de Morón, Buenos Aires.
7. «Leyes de evolución del Software». Connexions -
Educationalcontentrepository.
8. «Metodología para el análisis de Requisitos de Sistemas Software». Univ.
de Sevilla, 2001.
9. «Recommended Practice for Software Requirements Specification». IEEE-
SA Standards Board.
10.«Término "Elicitar"». 1ra. acepción - Wiktionary. Consultado el 15 de
diciembre de 2008.
11.Diccionario de la lengua española 2005 (2010). wordreference.com (ed.):
«software» (diccionario). Espasa-Calpe. Consultado el 1 de febrero de
2010.
12.IEEE Std, IEEE Software Engineering Standard: Glossary of Software
Engineering Terminology. IEEE Computer Society Press, 1993
13. Pressman, Roger S. (2003). «El proceso». Ingeniería del Software, un
enfoque Práctico, Quinta edición edición. Mexico: Mc Graw Hill.
14.Pressman, Roger S. (2003). «El producto». Ingeniería del Software, un
enfoque Práctico, Quinta edición edición. México: Mc Graw Hill.

61
15. Real Academia Española. «Significado de la palabra
Software». Diccionario de la Lengua Española, XXIIº Edición. Consultado
el 14 de marzo de 2008.
16.Real Academia Española. «Uso de la palabra Software». Diccionario
panhispánico de dudas, 1.° Edición (octubre 2005). Consultado el 8 de
febrero de 2009.
17.Software Requirements Engineering, 2nd Edition, IEEE Computer Society.
Los Alamitos, CA, 1997 (Compendio de papers y artículos en ingeniería de
requisitos)
18.Sommerville, Ian (2005). «21-Evolución del software». Ingeniería del
Software. España: Pearson Educación S.A.

62
ANEXO Nº 2: Fotografías
Centro Innovación y
emprendimiento
Agroindustrial
Balanza
automatizada
Compilación de códigos
Iniciamos la clase

63
Iniciamos todos los
objetos
Iniciamos todos los
objetos

64
Creación de contenedores
Creación de paneles

65
Creación de Labels Complejos
Creación de contenedor simple
Creación de imágenes
Creación de botones
Creación de paneles simples

66
Creación de líneas de trazo
simple
Creación de ítems template
Dimensionamiento automático
de escalas

67
Integración de elementos
Integración de elementos

68
Integración de referencias
Definición de variables

69
Declaraciones del API
Funciones privadas
Funciones privadas
Sentencias

70
Automatización de Word
Automatización de PDF
Finalizamos el objeto
Finalizamos la clase (y todos los objetos)

Informe de ppp desarrollo de software

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Informe de ppp desarrollo de software (20)

Último (10)

Informe de ppp desarrollo de software