Tesina

SunnySeed

Reporte de estada para la presentacin de examen profesional

para obtener el ttulo de:

Tcnico Superior Universitario

En
Tecnologas de la Informacin y Comunicacin
rea Sistemas Informticos.

Elaborado por:
Alan De Jess Daz Flores.

Ramos Arizpe, Coahuila

Fecha da/mes/ao

Tesina

SunnySeed

Reporte de estada para la presentacin de examen profesional

para obtener el ttulo de:

Tcnico Superior Universitario

en
Tecnologas de la Informacin y Comunicacin
rea Sistemas Informticos.
Elaborado por:
Alan De Jess Daz Flores.

Ramos Arizpe, Coahuila

Fecha da/mes/ao

Proyecto

SunnySeed

Que para obtener el ttulo de:

Tcnico Superior Universitario

En
Tecnologas de la Informacin y Comunicacin
rea Sistemas informticos.

Presenta
Alan De Jess Daz Flores.

Ramos Arizpe, Coahuila

Fecha da/mes/ao

Ramos Arizpe, Coahuila a, Fecha da mes ao

C. Nombre completo del alumno

P r e s e n t e.-

Los miembros del comit de revisin de tesina, recomendamos que el Proyecto

SunnySeed, realizado por Alan De Jess Daz Flores durante el periodo de
Estada Empresarial, en la empresa UTC donde se realiz el proyecto, sea
aceptado para obtener el

Ttulo de Tcnico Superior Universitario en

Tecnologas de la Informacin y Comunicacin Sistemas informticos.

Comit de Revisin

________________________________
Ttulo y nombre del maestro
Asesor Acadmico

_____________________________
M.A.T.I Federico U. Cruz Arcos
Director Acadmico

Carta de liberacin del proyecto

Nombre de la empresa

Direccin
__________

Fecha

Universidad Tecnolgica de Coahuila

Ave. Industria Metalrgica #2001
Parque Industrial Ramos Arizpe
Ramos Arizpe Coahuila

Por
medio
de
la
presente
hacemos
constar
que
el
Sr(a)
_________________________ con nmero de matrcula ______________ alumno
de la carrera _________________________________, entreg satisfactoriamente el
proyecto ____________________________________________.
Con base en los resultados esperados y lo entregado, se avala el cumplimiento
de los objetivos y metas planteados al inicio del proyecto.

Se extiende la presente para los fines que al interesado convenga en la ciudad de

____________________________________
_____________________________________.

los

Atentamente

<Lider del proyecto por parte de la empresa>

<Puesto>

<Tutor empresarial> (En

caso de ser distinto)
<Puesto>

NDICE
CAPTULO 1
1.1 INTRODUCCIN
1.2 ANLISIS DE LA SITUACIN
1.2.1 ANTECEDENTES
1.2.2 REA DE OPORTUNIDAD
1.2.3 EVALUACIN DIAGNSTICA
1.3 JUSTIFICACIN
1.4 OBJETIVOS
CAPTULO 2
2.1 DESARROLLO DEL PROYECTO
2.1.1 METODOLOGA
2.1.2 MARCO TERICO
2.1.3 DESARROLLO
2.1.4 ANLISIS DE RESULTADOS
CAPTULO 3
3.1 CONCLUSIONES
3.2 GLOSARIO
3.3 BIBLIOGRAFA
3.4 ANEXOS
3.4.1 CRONOGRAMA DE ACTIVIDADES
3.4.2 CONTRIBUCIONES ADICIONALES

1
2
3
8
8
9
10
10
11
11
11
12
30
31
32
33
33
34
34

CAPTULO 1

1.1

INTRODUCCIN

El proyecto SunnySeed, tiene como finalidad realizar una aplicacin web con el
objetivo de recabar informacin y recomendar un tipo de planta adecuada para su
plantacin en ciertas reas con el propsito de asegurar un crecimiento adecuado
para la misma.
Anlisis realizados en la localidad de Arteaga, Coahuila, se detect que un 40% de
los jardines y reas verdes de la regin que son pobladas con plantas, no se logra el
correcto crecimiento de las mismas, la mayora de las veces ocurre por no recibir
asesora de los requisitos para que una de estas poblaciones crezca saludable, esto
ocasiona una inversin nula e inversa por parte de quien es interesado en realizar
estas poblaciones de plantas.
El desarrollo de SunnySeed ayudar a la decisin de las personas interesadas en la
creacin de estas reas verdes con la esperanza de lograr correctamente el proceso
de crecimiento de las mismas y de la misma manera proyectando un impacto positivo
en el medio ambiente y a las inversiones realizadas por quienes son interesados en
el tema.
Los principales factores a considerar en el desarrollo de la aplicacin son: Tiempo de
desarrollo, Usabilidad de la aplicacin y Competencia en el mercado.
En cuanto a la parte tcnica de SunnySeed, se pretende tener un panel web en el
cual se vaci la informacin recabada que permita la validar la calidad de las
condiciones para semillas existentes en una base de datos previamente realizada.

1.2

ANLISIS DE LA SITUACIN

1.2.1. ANTECEDENTES
Anteriormente no se conoce la existencia de proyectos similares.
En cambio se han encontrado aplicaciones similares que sirven para la identificacin
de plantas basados en imgenes.

1.2.2. REA DE OPORTUNIDAD

Al momento de observar las reas verdes de la localidad, se detect que muchas de
ellas no estaban conformadas por poblaciones de plantas, con base a esto se
procedi a investigar lo que ocurra.
Se realiz una investigacin en la cual fue confirmado que la plantacin de estas
reas haba sido hecha unos meses antes y que por desgracias las plantas no
sobrevivieron, para poder proceder con el proyecto, tambin se cuestion sobre el
tipo de planta que se insert en el rea y que requerimientos tiene para su
crecimiento.
Da con da se llev a cabo el anlisis del avance en el cremento de la planta;
tambin se trat de mantener la planta en condiciones ptimas para su crecimiento,
pero muchos de estos factores no pudieron ser controlados.

1.2.3. EVALUACIN DIAGNSTICA

Anlisis FODA es una herramienta multifuncional la cual estamos utilizando en este

proyecto para poder determinar las cualidades y virtudes de dicho proyecto.

Fortalezas

Debilidades

-Aplicacin de las nuevas tecnologas.

- Falta de dispositivos electrnicos.

-Engloba informacin en un solo sitio.

- Requiere de tiempo para recabar la

-Conocimiento de tcnicas para.

informacin.

-desarrollo web.

- Fallas en la aplicacin.
- Tiempo muerto de desarrollo.

Oportunidades

Amenazas

- Poca competencia.

- Aumento de precio de dispositivos

- Tendencias favorables en el mercado.

electrnicos.
-Falta de inters en el mercado.

1.3 JUSTIFICACIN
El desarrollo de SunnySeed se realiz ya que al visualizar las reas verdes estas
no eran lo esperado, se not la enorme ausencia de plantas, el estado deplorable de
las pocas que se encontraron y apariencia descuidada.
Se realizara la aplicacin web para monitorear estas reas y recabar la informacin
necesaria para dar la recomendacin sobre la semilla a plantar, el tiempo y la calidad
de luz natural, humedad, tipo de clima, suelo, etc
Todos esos factores involucrados en el crecimiento de las plantas y que de esta
manera se generar un ahorro en la inversin de las personas involucradas en estos
procesos y el beneficio para el medio ambiente.

1.3

OBJETIVOS
I. Crear la aplicacin web que integre la informacin sobre las plantas.
II. Administrar la informacin que se recabe con los dispositivos electrnicos
III. Mostrar si el rea es apta para la plantacin de semillas de rosal.
IV. Monitorear el crecimiento y desarrollo de estas semillas.

CAPTULO 2
2.1

DESARROLLO DEL PROYECTO

2.1.1 METODOLOGA
Del PEN Book utilizaremos la herramienta WBS.
SunnySeed

1.

INICIO

1.1 Introduccin

2. PLANEACION

2.1 WBS

3. EJECUCIN

3.1 Desarrollo de la app

4. CIERRE
5.1 Generar documentacin

2.2 Project Charter

1.2
3.2
Antecedentes.
Pruebas de integridad.
2.3 Cronograma de actividades
1.3
Definir el proyecto

5.2 Entrega de documentacin

2.1.2 MARCO TERICO

Hoy en da el procedimiento que se lleva a cabo para la siembra, se ejecuta
mediante un conjunto de conocimientos basados en la experiencia, siendo muy difcil
al momento de sembrar nuevas reas, presentando una serie de problemas durante
el crecimiento y desarrollo de dichas reas, ya que los ciudadanos de ciertas
localidades no tienen este conocimiento, se hace difcil la correcta implementacin de
las tcnicas correctas para asegurar el desarrollo y crecimiento de las plantas.
Las plantas necesitan del suelo, aire, agua y luz; los mismos elementos que necesita
el ser humano para poder sobrevivir, al eliminarle uno slo de ellos mueren.
Suelo
El suelo es la capa superficial de la corteza terrestre. En l la semilla germina y la
planta ahonda las races para mantenerse derecha, desarrollarse y nutrirse. Hay que
protegerla
En el suelo las plantas encuentran todos los nutrientes indispensables para subsistir.
Cada uno de esos nutrientes tiene una funcin especfica: el fsforo permite el
crecimiento; el nitrgeno estimula la produccin de hojas abundantes; el potasio y el
calcio favorecen el desarrollo armnico de los vegetales y el hierro aumenta la
coloracin verde.
Si el suelo es pobre en uno de estos elementos, la planta sufre y muestra signos de
alteraciones en su desarrollo (crece como un nio desnutrido, es decir que no ha
recibido la alimentacin adecuada).
Aire
El aire es un elemento necesario para la vida del hombre, animales y plantas; sin l
no podramos vivir.
Las plantas no viven si les falta el aire.

Luz
As como el ser humano necesita de una buena alimentacin, adems de vitaminas
para obtener energa, las plantas verdes utilizan la energa del SOL para subsistir. A
partir del sol, fabrican su propio alimento, por eso se les llaman organismos
productores, porque producen su propio alimento.

Agua
El Agua al igual que el aire, la luz y el suelo constituye otro de los elementos bsicos
e indispensables para que las plantas germinen y logren el crecimiento deseado.
Es funcin entonces del agua disolver los nutrientes que se encuentran dispersos en
el suelo para facilitarle a la planta la absorcin de los mismos.
Este conjunto de datos tienden a ser especficos para ciertas plantas y como ocurre
con las personas experimentadas en este tema, conocen si no perfectamente las
variantes entre ellas.
En grandes empresas dedicadas a la agricultura ya tienen especialistas en este
campo, que conocen y saben aplicar los conocimientos sobre estas caractersticas
para el aprovechamiento de las mismas en el crecimiento de plantas, un ejemplo de
estas empresas sera grupo Herdez, empresa que destina millones de dlares para
el estudio de zonas con potencial agrcola.
La empresa Herdez ha capacitado personal especfico para el estudio de posibles
nuevas reas agrcolas, en dichos estudios se toman en cuenta los factores antes
mencionados esenciales para el desarrollo y crecimiento de plantas dependiendo del
rea.

Un claro ejemplo de esto es que no podramos hacer crecer una palmera de cocos
en
el fro clima de Alaska, eso por lgica nadie lo hara pero digamos que en casos ms
especficos quien conoce la diferencia entre un rosal y un tulipn, para ciudadanos
comunes, estas dos son plantas ornamentales las cuales adornan nuestros hogares
o algunas reas verdes, sin embargo se ha notado que en zonas especficas el rosal
tiende a sobrevivir ms tiempo que el tulipn, el mismo caso para estos.
Esto se debe a los diferentes requisitos que ambos llegan a tener dependiendo de
distintos factores, como lo son:
-Clima.
-Caractersticas del selo.
-Poda.
-Agua necesaria.
-Abono.
-Variedades entre sus tipos.
Resumen. La floricultura es considerada como una actividad competitiva y vinculada
con la economa global. Su prctica se limita a ciertas regiones, entre ellas el
municipio de Villa Guerrero, Estado de Mxico, cuyo potencial florcola radica en las
caractersticas de los recursos naturales, as como en las condiciones sociales. Estas
cualidades han favorecido la participacin de las unidades de produccin familiar en
el mercado nacional y la ampliacin de la oferta de empleo local y regional, as como
el mejoramiento de los ingresos. Este trabajo muestra las caractersticas
socioeconmicas y tcnicas de la agricultura ornamental en las localidades de San
Felipe y Buenavista, en el escenario econmico de la competencia y del libre
mercado.

Para la aplicacin se piensa en que sea realizada en un desarrollo web y que permita
el acceso a ella desde cualquier sitio y dispositivo con conectividad a internet, esta
misma tendr una base de datos independiente.
Las aplicaciones web generalmente se componen por un servidor web, el cual realiza
las acciones y tareas definidas por un cliente web, El desarrollo de estas aplicaciones
ha permitido la creacin de distintas metodologas y modelos que facilitan el mismo
desarrollo, un ejemplo de estas tcnicas es la creacin de frameworks que permiten
un desarrollo gil y escalable permitiendo la integracin de distintas tecnologas as
como lenguajes de programacin para satisfacer las necesidades del proyecto.
La versatilidad de los motores de bases de datos actuales hacen posible un mejor
rendimiento para aplicaciones de alto impacto y de requerimientos exigentes, Est de
ms mencionar que muchas de las empresas conocidas por sus desarrollos de
aplicaciones impactantes ya utilizan estos mtodos y herramientas a las cuales se
les debe parte de su gran funcionalidad.
Un claro ejemplo de empresas que utilizan las herramientas y mtodos mencionados
sera la empresa Facebook que gracias a su capacidad creativa y operativa han
logrado ser una de las grandes redes sociales permitiendo al usuario gran variedad
de tareas dentro de su aplicacin y en la cual el uso de bases de datos NoSQL le ha
permitido una gran escalabilidad hasta lograr un alcance global.

2.1.3 DESARROLLO
Durante el transcurso de la creacin de esta aplicacin, se realiz una investigacin
sobre los tipos de plantas y sus caractersticas ptimas para el crecimiento, de igual
manera se verti toda la informacin arrojada por esta investigacin en una base de
datos con el motor SLQ Server 2008 R2, logrando as la concentracin de la
informacin en un solo sitio y de fcil acceso desde una interfaz grfica la cual
contiene mdulos representativos de la informacin para su fcil anlisis.
Una vez recabados los datos, se procedi a la creacin de la interfaz grfica usando
las normas ISO (International Standart Organitation) de usabilidad, diseo y confort,
las normas utilizadas fueron las siguientes:
-ISO 9001: este es un estndar que describe el sistema de calidad utilizado para
mantener el desarrollo de un producto que implique diseo.

-ISO/IEC 12207: Information Technology / Software Life Cycle Processes, es el

estndar para los procesos de ciclo de vida del software de la organizacin ISO.

-ISO 9000-3: son los estndares utilizados para el desarrollo, suministro y

mantenimiento del software.

-ISO 9241-11: Orientacin sobre Usabilidad (1998)

Este estndar (que es parte de la serie ISO 9241 fuera del sitio) proporciona la
definicin de usabilidad que se utiliza en los estndares ergonmicos posteriores
relacionados:
Facilidad de uso: el grado en que un producto puede ser usado por determinados
usuarios para conseguir objetivos especficos con efectividad, eficiencia y
satisfaccin en un contexto de uso.
-ISO 9004-2: este documento proporciona las directrices para el servicio de
facilidades del software como soporte de usuarios.

-ISO/IEC 9126: Evaluacin del producto Software - las caractersticas de calidad y

directrices para su uso (1991) en la comunidad de ingeniera del software el trmino
usabilidad se ha asociado ms estrechamente a diseo de interfaz de usuario.
ISO/IEC 9126, desarrollado por separado como una ingeniera de software estndar,
define usabilidad como una contribucin relativamente independiente a la calidad de
software asociado con el diseo y evaluacin de la interfaz de usuario y la
interaccin: usabilidad: un conjunto de atributos que en el esfuerzo necesario para su
uso y en la evaluacin individual de tal uso, por un conjunto de usuarios declarado o
implcito.

-ISO 9241: Requisitos ergonmicos para trabajos de oficina con pantalla visual
terminalsISO 9241 proporciona requisitos y recomendaciones relativas a los atributos
de hardware, software y entorno que contribuyen a la usabilidad y los ergonoma
principios les. Piezas de 10 y 12 a 17 tratan especficamente atributos del software.
Piezas 14-17 estn destinadas a ser utilizados por los diseadores y evaluadores de
interfaces de usuario, pero el enfoque es principalmente hacia el diseador.
-ISO 13407: Procesos de diseo centrado en humanos para sistemas interactivos
(1999) esta norma proporciona orientacin sobre las actividades de diseo centrado

en el humano durante todo el ciclo de vida de sistemas interactivos basados en

computadoras. Es una herramienta para los procesos de diseo manejo y
proporciona una gua de fuentes de informacin y normas pertinentes al enfoque
centrado en el humano. Diseo centrado en humanos describe como una actividad
multidisciplinaria, que incorpora el conocimiento humano de factores y la ergonoma
y tcnicas con el objetivo de mejorar la eficacia y la eficiencia, mejorar las
condiciones de trabajo humanas y contrarrestar los posibles efectos adversos de uso
en salud humana, seguridad y rendimiento., pero el enfoque es principalmente hacia
el diseador.
Con el cumplimiento de estas normas ISO, se otorga de ergonoma y confort a la
interfaz grfica.
De igual manera para el trabajo en back-end del software se establecieron los
siguientes reglamentos y estndares:

C++ Coding Standard

Purpose
To guide implementation of C++ programs
Program
Begin all programs with a descriptive header.
Headers
Header
/******************************************************************/
Format
/* Program Assignment: the program number
*/
/* Name:
your name
*/
/* Date:
the date you started developing the
program
*/
/* Description:
a short description of the program
and what it does
*/
/******************************************************************/
Listing
Provide a summary of the listing contents
Contents
Contents
/******************************************************************/
Example
/* Listing Contents:
*/
/* Reuse instructions
*/
/* Modification instructions

Reuse
Instructions

Reuse
Instruction
Example

Identifiers
Identifier
Example
Comments

*/
/* Compilation instructions
*/
/* Includes
*/
/* Class declarations:
*/
/*
CData
*/
/*
ASet
*/
/* Source code in c:/classes/CData.cpp:
*/
/*
CData
*/
/*
CData()
*/
/*
Empty()
*/
/******************************************************************/
- Describe how the program is used: declaration format,
parameter values, types, and formats.
- Provide warnings of illegal values, overflow conditions, or
other conditions that could potentially result in improper
operation.
/******************************************************************/
/* Reuse instructions
*/
/*
int PrintLine(char *line_of_character)
*/
/*
Purpose: to print string, line_of_character, on one
print line
*/
/*
Limitations: the line length must not exceed
LINE_LENGTH
*/
/*
Return 0 if printer not ready to print, else 1
*/
/******************************************************************/
Use descriptive names for all variable, function names,
constants, and other identifiers. Avoid abbreviations or singleletter variables.
Int number_of_students;
/* This is GOOD */
Float: x4, j, ftave;
/* This is BAD */
- Document the code so the reader can understand its
operation.
- Comments should explain both the purpose and behavior of
the code.

Good
Comment
Bad Comment
Major
Sections
Example

Blank Spaces

- Comment variable declarations to indicate their purpose.

If(record_count > limit) /* have all records been processed?
*/
If(record_count > limit) /* check if record count exceeds limit
*/
Precede major program sections by a block comment that
describes the processing done in the next section.
/******************************************************************/
/* The program section examines the contents of the array
grades and calcu- */
/* lates the average class grade.
*/
/******************************************************************/
- Write programs with sufficient spacing so they do not appear
crowded.
- Separate every program construct with at least one space.

C++ Coding Standard (continued)

Indenting
- Indent each brace level from the preceding level.
- Open and close braces should be on lines by themselves and
aligned.
Indenting
while (miss_distance > threshold)
Example
{
success_code = move_robot (target _location);
if (success_code == MOVE_FAILED)
{
printf(The robot move has failed.\n);
}
}
Capitalization - Capitalize all defines.
- Lowercase all other identifiers and reserved words.
- To make them readable, user messages may use mixed
case.
Capitalization #define DEFAULT-NUMBER-OF-STUDENTS 15
Examples
int class-size = DEFAULT-NUMBER-OF-STUDENTS;

PSP1 Process Script

Purpose
To guide the development of module-level programs
Entry Criteria
- Problem description
- PSP1 Project Plan Summary form
- Size Estimating template
- Historical size and time data (estimated and actual)

- Time and Defect Recording logs

- Defect Type, Coding, and Size Counting standards
- Stopwatch (optional)

Ste
p
1

Activities

Description

Planning

Development

Postmortem

- Produce or obtain a requirements statement.

- Use the PROBE method to estimate the added and
modified size of this program.
- Complete the Size Estimating template.
- Use the PROBE method to estimate the required
development time.
- Enter the plan data in the Project Plan Summary form.
- Complete the Time Recording log.
- Design the program.
- Implement the design.
- Compile the program, and fix and log all defects found.
- Test the program, and fix and log all defects found.
- Complete the Time Recording log.
Complete the Project Plan Summary form with actual
time, defect, and size data.

Exit Criteria

- A thoroughly tested program

- Completed Project Plan Summary form with estimated
and actual data
- Completed Size Estimating template
- Completed Test Report template
- Completed PIP forms
- Completed Time and Defect Recording logs

Revisiones de cdigo y estndares de codificacin

Un estndar de codificacin completo comprende todos los aspectos de la
generacin de cdigo. Si bien los programadores deben implementar un estndar de

forma prudente, ste debe tender siempre a lo prctico. Un cdigo fuente completo
debe reflejar un estilo armonioso, como si un nico programador hubiera escrito todo
el cdigo de una sola vez. Al comenzar un proyecto de software, establezca un
estndar de codificacin para asegurarse de que todos los programadores del
proyecto trabajen de forma coordinada. Cuando el proyecto de software incorpore
cdigo fuente previo, o bien cuando realice el mantenimiento de un sistema de
software creado anteriormente, el estndar de codificacin debera establecer cmo
operar con la base de cdigo existente.
La legibilidad del cdigo fuente repercute directamente en lo bien que un
programador comprende un sistema de software. La mantenibilidad del cdigo es la
facilidad con que el sistema de software puede modificarse para aadirle nuevas
caractersticas, modificar las ya existentes, depurar errores, o mejorar el rendimiento.
Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una
faceta del desarrollo de software en la que todos los programadores influyen
especialmente es en la tcnica de codificacin. El mejor mtodo para asegurarse de
que un equipo de programadores mantenga un cdigo de calidad es establecer un
estndar de codificacin sobre el que se efectuarn luego revisiones del cdigo de
rutinas.
Usar tcnicas de codificacin slidas y realizar buenas prcticas de programacin
con vistas a generar un cdigo de alta calidad es de gran importancia para la calidad
del software y para obtener un buen rendimiento. Adems, si se aplica de forma
continuada un estndar de codificacin bien definido, se utilizan tcnicas de
programacin apropiadas, y, posteriormente, se efectan revisiones del cdigo de
rutinas, caben muchas posibilidades de que un proyecto de software se convierta en
un sistema de software fcil de comprender y de mantener.
Aunque el propsito principal para llevar a cabo revisiones del cdigo a lo largo de
todo el desarrollo es localizar defectos en el mismo, las revisiones tambin pueden
afianzar los estndares de codificacin de manera uniforme. La adopcin de un
estndar de codificacin slo es viable si se sigue desde el principio hasta el final del
proyecto de software. No es prctico, ni prudente, imponer un estndar de
codificacin una vez iniciado el trabajo.

Las tcnicas de codificacin incorporan muchos aspectos del desarrollo del software.
Aunque generalmente no afectan a la funcionalidad de la aplicacin, s contribuyen a
una mejor compresin del cdigo fuente. En esta fase se tienen en cuenta todos los
tipos de cdigo fuente, incluidos los lenguajes de programacin, de secuencias de
comandos, de marcado o de consulta.
Las tcnicas de codificacin aqu definidas no pretenden formar un conjunto inflexible
de estndares de codificacin. Ms bien intentan servir de gua en el desarrollo de un
estndar de codificacin para un proyecto especfico de software.

Las tcnicas de codificacin estn divididas en tres secciones:

Nombres

Comentarios

Formato

Nombres
El esquema de nombres es una de las ayudas ms importantes para entender el flujo
lgico de una aplicacin. Un nombre debe ms bien expresar el "qu" que el "cmo".
Si evita nombres que se refieran a la implementacin subyacente (sujeta a cambios),
estar conservando un grado de abstraccin que lo simplificar todo. Por ejemplo,
puede usar GetNextStudent() en vez de GetNextArrayElement().
El inters de poner un nombre es que la dificultad para escoger uno adecuado puede
indicar que se necesita analizar o definir con mayor precisin el propsito de un
elemento. Ponga nombres lo suficientemente largos para que sean elocuentes, pero
lo bastante cortos como para que no pequen de palabrera. Desde el punto de vista
de la programacin, un nombre nico sirve solamente para diferenciar un elemento
de otro. Los nombres expresivos funcionan como ayuda para el lector, por eso, es
lgico dar nombres que sean fciles de comprender. No obstante, asegrese de que
los nombres escogidos sean compatibles con las reglas de cada lenguaje y con los
estndares.
Los siguientes puntos son tcnicas de nomenclatura recomendadas.
Rutinas

Se evit usar nombres imprecisos que permitan interpretaciones subjetivas,

como por ejemplo AnalyzeThis() para una rutina, o bien xxK8 para una
variable. Tales nombres contribuyen ms a la ambigedad que a la
abstraccin.

En lenguajes orientados a objetos se incluyeron nombres de clases en el

nombre de las propiedades de clases, como por ejemplo Book.BookTitle. En
su lugar, utilice Book.Title.

Se us el mtodo verbo-sustantivo para dar nombre a las rutinas que ejecuten

alguna operacin en un determinado objeto, como por ejemplo
CalculateInvoiceTotal().

En lenguajes que permitan sobrecarga de funciones, todas las sobrecargas

llevaron a cabo una funcin similar. Para los lenguajes que no permitan la
sobrecarga de funciones, establezca una nomenclatura estndar relacionada
con funciones similares.

Variables

Se aadieron calificadores de computacin (Avg, Sum, Min, Max, Index)

despus de un nombre de variable donde le resulte apropiado.

Se utilizaron pares complementarios en nombres de variables, como min/max,

begin/end, y open/close.

Dado que la mayora de nombres se construyeron concatenando varias

palabras, se emple una mezcla de maysculas y minsculas para simplificar
la lectura. Adems, para ayudar a distinguir entre variables y rutinas, se utiliz
el mtodo Pascal de maysculas y minsculas (CalculateInvoiceTotal) para los
nombres de rutinas, en el que la primera letra de cada palabra est en
mayscula. Para las variables, ponga la primera letra de cada palabra en
mayscula, exceptuando la primera (documentFormatType).

Los nombres de variables booleanas se les dio el prefijo Is, lo que implica
valores del tipo Yes/No o True/False, como por ejemplo fileIsFound.

Se evit usar trminos del tipo Flag cuando ponga nombre a variables de
estado, que difieren de las variables booleanas en que aqullas tuvieron ms
de dos valores posibles. En vez de documentFlag, utilice un nombre ms
descriptivo, del tipo documentFormatType.

Incluso para el caso de una variable de poco uso, que deba aparecer slo en
unas cuantas lneas de cdigo, emplee un nombre descriptivo. Utilizamos
nombres de variables de una sola letra, como i o j slo para ndices cortos.

No utilizamos nmeros o cadenas literales, como por ejemplo For i = 1 To 7.

En su lugar, emplee constantes con nombre, del tipo For i = 1 To
NUM_DAYS_IN_WEEK para que resulten fciles de mantener y comprender.

Tablas

Cuando colocamos los nombres a las tablas, lo hicimos en singular. Por

ejemplo, usamos Employee en lugar de Employees.

Cuando dimos nombre a las columnas de las tablas, no repetimos el nombre

de la tabla; por ejemplo, evitamos un campo llamado EmployeeLastName de
una tabla llamada Employee.

No incorporamos el tipo de datos en el nombre de una columna. As reducir

el esfuerzo que podra ser necesario posteriormente para cambiar el tipo de
datos.

Microsoft SQL Server

No usamos prefijos sp a los procedimientos almacenados, ya que se trata de

un prefijo reservado para la identificacin de procedimientos almacenados de
sistemas.

No usamos prefijos fn_ a las funciones definidas por el usuario, ya que se trata
de un prefijo reservado para funciones integradas.

No usamos prefijos xp_a los procedimientos almacenados extendidos, ya que

se trata de un prefijo reservado para la identificacin de procedimientos
almacenados extendidos.

Varios

Minimizamos el uso de abreviaturas; pero s las emplea, usamos

coherentemente las que haya creado. Una abreviatura slo debe tener un
significado y, del mismo modo, a cada palabra abreviada slo debe
corresponder una abreviatura. Por ejemplo, utilizamos "min." para abreviar
"mnimo", siempre lo hicimos as, y no usamos tambin "min." para abreviar
"minuto".

Cuando dimos nombre a las funciones, incluimos una descripcin del valor
que vaya a ser devuelto, como por ejemplo GetCurrentWindowName().

Los archivos y los nombres de carpetas, al igual que los nombres de

procedimientos, estn descritos claramente su finalidad.

Evitamos reutilizar nombres para elementos diferentes, como por ejemplo una
rutina llamada ProcessSales() y una variable iProcessSales.

Evitamos los homnimos, como write y right, para evitar confusiones durante
las revisiones del cdigo.

Al dar nombre a los elementos, evitamos las palabras mal escritas

comnmente. tambin tuvimos cuidado con las diferencias que existen entre
las diferentes variedades regionales del idioma.

Evitamos las marcas tipogrficas para identificar tipos de datos, como $ para
las cadenas, o % para los enteros.

Comentarios
Existen dos tipos de documentacin de software: externa e interna. La
documentacin externa, como por ejemplo las especificaciones, los archivos de
ayuda y los documentos de diseo, se mantiene fuera del cdigo fuente. La
documentacin interna est formada por los comentarios que los programadores
escriben dentro del cdigo fuente durante la fase de desarrollo.
Pese a la disponibilidad de la documentacin externa, debe contarse con listados
independientes del cdigo fuente, por si se perdiera la documentacin de
recuperacin impresa. La documentacin externa puede constar de especificaciones,
documentos de diseo, peticiones de cambios, historial de errores y el estndar de
codificacin empleado.
Uno de los problemas de la documentacin de software interna es garantizar que se
mantienen y actualizan los comentarios al mismo tiempo que el cdigo fuente.
Aunque unos buenos comentarios en el cdigo fuente no tienen ningn valor en el

tiempo de ejecucin, resultan valiossimos para un programador que tenga que

mantener una parte de software particularmente intrincada o compleja.
Los siguientes puntos son tcnicas de comentarios recomendadas.

Utilizamos la funcin de documentacin XML. Para obtener ms informacin,

vea Documentacin XML.

Modificamos el cdigo, mantenga siempre actualizados los comentarios

circundantes.

Al principio de cada rutina, resulto ser til hacer comentarios estndar,

repetitivos, que indicaron el propsito de la rutina, las suposiciones y las
limitaciones. Un comentario repetitivo podra consistir en una breve
introduccin que explicara por qu existe y qu puede hacer.

Evitamos aadir comentarios al final de una lnea de cdigo, porque lo hacen

ms difcil de leer. Sin embargo, los comentarios de final de lnea s son
apropiados al anotar declaraciones de variables. En este caso, se alinearon
todos los comentarios de final de lnea en la misma posicin de tabulacin.

Evitamos los comentarios recargados, como las lneas enteras de asteriscos.

En su lugar, utilizamos espacios para separar los comentarios y el cdigo.

Evitamos rodear un bloque de comentarios con un marco tipogrfico. Puede

resultar agradable, pero es difcil de mantener.

Antes de la implementacin, quitamos todos los comentarios temporales o

innecesarios, para evitar cualquier confusin en la futura fase de
mantenimiento.

Necesitamos realizar comentarios para explicar una seccin de cdigo

compleja, examinamos el cdigo para decidir si debera volver a escribirlo.
Siempre que fuese posible, no documentamos un cdigo malo, volvimos a
escribirlo. Aunque, por regla general, no debimos sacrificar el rendimiento para
hacer un cdigo ms simple para el usuario, es indispensable un equilibrio
entre rendimiento y mantenibilidad.

Usamos frases completas cuando escribimos comentarios. Los comentarios

aclararon el cdigo, no le aadimos ambigedad.

Fuimos comentando al mismo tiempo que programando, porque no tuvimos

tiempo de hacerlo ms tarde. Por otro lado, aunque tuviera oportunidad de
revisar el cdigo que ha escrito, lo que parece obvio hoy es posible que seis
semanas despus no lo sea.

Evitamos comentarios superfluos o inapropiados, como comentarios divertidos

al margen.

Usamos los comentarios para explicar el propsito del cdigo. No los usamos
como si fueran traducciones interlineales.

Comentamos cualquier cosa que no sea legible de forma obvia en el cdigo.

Para evitar problemas recurrentes, siempre comentamos al depurar errores y

solucionar problemas de codificacin, especialmente cuando trabajamos en
equipo.

Comentamos en el cdigo que est formado por bucles o bifurcaciones

lgicas. Se trata en estos casos de reas clave que ayudarn a los lectores
del cdigo fuente.

Realizamos los comentarios en un estilo uniforme, respetando una puntuacin

y estructura coherentes a lo largo de toda la aplicacin.

Separamos los comentarios de sus delimitadores mediante espacios.

Respetamos estas normas, los comentarios fueron ms claros y fciles de
localizar si trabaja sin indicaciones de color.

Formato
El formato hace que la organizacin lgica del cdigo sea ms clara. Tomamos el
tiempo de comprobar que el cdigo fuente posee un formato coherente y lgico, les
resultar de gran utilidad a usted y a otros programadores que tengan que
descifrarlo.

Los siguientes puntos son tcnicas de formato recomendadas.

Establecimos un tamao estndar de sangra (por ejemplo, cuatro espacios) y

selo siempre. Alineamos las secciones de cdigo mediante la sangra
predeterminada.

Usamos un nico tipo de letra cuando publique versiones impresas del cdigo
fuente.

Alineamos verticalmente las llaves de apertura y cierre donde los pares de

llaves se alinean, como por ejemplo en:
Copiar
for (i = 0; i < 100; i++)
{
...
}
Tambin puede usar un estilo inclinado, en el que las llaves de apertura
aparezcan al final de la lnea y las de cierre al principio, como por ejemplo en:
Copiar
for (i = 0; i < 100; i++){
...
}

aplicamos una sangra al cdigo en todas las lneas de construccin lgica. Si

no aplicamos la sangra, el cdigo resulta difcil de seguir, como ocurre en:
Copiar
If ... Then

If ... Then
...
Else
End If
Else
...
End If
La sangra aplicada al cdigo hace que ste sea ms fcil de leer, como por
ejemplo en:
Copiar
If ... Then
If ... Then
...
Else
...
End If
Else
...
End If

establecimos una longitud de lnea mxima para los comentarios y el cdigo.

As no tendr que desplazarse en el editor del cdigo fuente, y conseguir
presentaciones impresas claras.

Utilizamos espacios antes y despus de los operadores siempre que eso no

altere la sangra aplicada al cdigo. Una excepcin es, por ejemplo, la pointer
notation usada en C++.

Usamos espacios en blanco para proporcionar indicaciones organizativas del

cdigo fuente. As, crear "prrafos" de cdigo, que ayudarn al lector a
comprender la segmentacin lgica del software.

Cuando tuvimos que dividir una lnea en varias, aclare que el cdigo sigue en
la lnea de ms abajo mediante un operador de concatenacin colocado al
final de cada lnea, y no al principio.

Fue posible, no coloque ms de una instruccin por lnea. Una excepcin es

un bucle en C, C++, C#, o JScript, como en for (i = 0; i < 100; i++).

Al escribir en HTML, establecimos un formato estndar para las etiquetas y los

atributos; como por ejemplo, las etiquetas siempre en mayscula y los
atributos en minscula. Como alternativa, siga las convenciones de la
especificacin XHTML para asegurarse de que los documentos HTML son

vlidos. Aunque existe una tamao razonable que debe tenerse en cuenta a la
hora de crear pginas Web, utilice valores de atributo entre comillas y
etiquetas de cierre, para una mejor mantenibilidad.

Cuando escribimos instrucciones SQL utilice maysculas para las palabras

clave y maysculas y minsculas para los elementos de la base de datos,
como tablas, columnas y vistas.

Dividimos el cdigo fuente de manera lgica entre diferentes archivos.

Coloque las clusulas SQL principales en lneas separadas, de modo que las
instrucciones sean ms fciles de leer y editar. Por ejemplo:
Copiar
SELECT FirstName, LastName
FROM Customers
WHERE State = 'WA'

Dividimos las secciones de cdigo grandes y complejas en otras ms

pequeas y comprensibles. .

2.1.4 ANLISIS DE RESULTADOS

Con el fin de lograr los objetivos planteados al inicio de esta tesis, se presenta el
siguiente anlisis de resultados por preguntas.
Qu impacto causo la demostracin de la aplicacin?
En 7 de 10 personas a las que se les mostr la aplicacin pareci interesado en el
cuidado del medio ambiente, siendo en su mayora personas identificadas con la
prdida econmica por invertir en plantas.
Calificacin obtenida por los usuarios?
En promedio se le dio un 7.2 de promedio entre:
-popularidad
-usabilidad
-precio
-descargas
Se podra concluir con este anlisis de resultados con el siguiente enunciado:
Se not que la aplicacin tiene un futuro y si se le dedica el tiempo necesario para
lograr los objetivos, se sigue aplicando ms conocimiento de las nuevas tecnologas
y se hace la inversin necesaria para que llegue a su cspide, la aplicacin tiene
bastante potencial tanto a nivel funcional como econmico para quien decida llevar el
proyecto a produccin.

CAPTULO 3
3.1 CONCLUSIONES

El proyecto fue bien recibido, la presentacin del mismo fue un xito ya que se not
el inters del cliente en adquirir el producto, seguimos en negociacin para cerrar el
trato y comenzar a realizar el proyecto en produccin.
La tecnologa empleada dio buen resultado, el uso de las tecnologas de internet al
ser accesibles para cualquier persona en estos das son uno de los principales flujos
de ingresos.
Por otro lado, la usabilidad del sitio y la manera intuitiva de navegar por el han hecho
que sea un xito entre los casos de prueba que hemos realizado.

3.2 GLOSARIO
Ancho de banda (bandwidth): Capacidad de transmisin de informacin que te
permite saber la cantidad y la velocidad de los datos que fluyen en una red. Se aplica
siempre que la informacin pase por cualquier medio de transmisin.
Ethernet: Conexin estndar de la computadora a la red de datos a travs de un
cable.
HTTP (Hypertext Transfer Protocol): Protocolo utilizado para enviar y recibir
informacin de Internet al navegador.
Java: Lenguaje de programacin orientado a objetos. Se utiliza comnmente para
desarrollar aplicaciones en pginas web y equipos mviles como telfonos celulares.
Linux: Sistema operativo de cdigo abierto. Cualquier usuario puede contribuir a su
mejora. Para usarlo no se requiere licencia, es decir, es gratuito: esta es una de las
caractersticas por la que ms se le conoce.
QWERTY: Tipo de teclado utilizado desde la mquina de escribir hasta celulares.
Web: Sistema de interconexin de archivos y contenidos en Internet. Se representa
con WWW.
ZIP: Extensin de los documentos que contienen otros archivos comprimidos.
USB: (Universal Serial Bus): Terminal tipo serial para conexin entre dispositivos
perifricos y la computadora.
URL (Uniform Resource Locator): Identificador de los dominios de las pginas de
Internet.

3.3 BIBLIOGRAFA
Francis, R.C. (2011). Epigenetics: How environment shapes our genes.New York:
W.W. Norton.
Kagayame, J. and Sherman, J. (2012). Discovering the construct of time.New York:
Rosen Publishing.
Ashley, S. (2008, August). Sunny Days for Silicon. [electronic version].Scientific
American, 299 (8). Retrieved September 18, 2008
Benson, T. ( Nov 17, 2005). Forces on a Rocket. Retrieved on October 2, 2008, from
http://exploration.grc.nasa.gov/education/rocket/rktfor.html

3.4

CRONOGRAMA DE ACTIVIDADES