2.4: Desarrollo de Sistemas de Información
- Page ID
- 154035
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)Objetivos de aprendizaje
Al finalizar con éxito este capítulo, usted será capaz de:
- Explicar el proceso general de desarrollo de nuevo software;
- Explicar las diferencias entre las metodologías de desarrollo de software;
- Comprender los diferentes tipos de lenguajes de programación utilizados para desarrollar software;
- Comprender algunos de los problemas relacionados con el desarrollo de sitios web y aplicaciones móviles; y
- Identificar las cuatro políticas primarias de implementación.
Introducción
Cuando alguien tiene una idea para que una nueva función sea realizada por una computadora, ¿cómo se hace realidad esa idea? Si una empresa quiere implementar un nuevo proceso de negocio y necesita nuevo hardware o software para apoyarlo, ¿cómo hacen que suceda? Este capítulo abarca los diferentes métodos para tomar esas ideas y llevarlas a la realidad, un proceso conocido como desarrollo de sistemas de información.
Programación
El software se crea a través de la programación, como se discute en el Capítulo 2. La programación es el proceso de crear un conjunto de instrucciones lógicas para que un dispositivo digital las siga utilizando un lenguaje de programación. El proceso de programación a veces se llama “codificación” porque el desarrollador toma el diseño y lo codifica en un lenguaje de programación que luego se ejecuta en la computadora.
El proceso de desarrollar un buen software no suele ser tan sencillo como sentarse y escribir algún código. A veces un programador puede escribir rápidamente un programa corto para resolver una necesidad, pero en la mayoría de los casos la creación de software es un proceso intensivo de recursos que involucra a varios grupos diferentes de personas en una organización. Para hacer esto de manera efectiva, los grupos acuerdan seguir una metodología específica de desarrollo de software. En las siguientes secciones se revisan varias metodologías diferentes para el desarrollo de software, como se resume en la siguiente tabla y se describe con mayor detalle en las siguientes secciones.
Ciclo de vida de desarrollo de sistemas
El ciclo de vida de desarrollo de sistemas (SDLC) se desarrolló por primera vez en la década de 1960 para administrar los grandes proyectos de software asociados con los sistemas corporativos que se ejecutan en mainframes. Este enfoque de desarrollo de software es muy estructurado y reacio al riesgo, diseñado para gestionar grandes proyectos que incluyen múltiples programadores y sistemas que tienen un gran impacto en la organización. Requiere una comprensión clara y directa de lo que se supone que debe hacer el software y no es susceptible de cambios de diseño. Este enfoque es más o menos similar a un proceso de línea de montaje, donde es claro para todos los interesados qué debe hacer el producto final y que los cambios importantes son difíciles y costosos de implementar.
Existen diversas definiciones de la metodología SDLC, pero la mayoría contiene las siguientes fases.
- Análisis Preliminar. Primero se revisa una solicitud de reemplazo o sistema nuevo. La revisión incluye preguntas como: ¿Cuál es el problema a resolver? ¿Es posible crear una solución? ¿Qué alternativas existen? ¿Qué se está haciendo actualmente al respecto? ¿Este proyecto es una buena opción para nuestra organización? Después de abordar esta cuestión, se pone en marcha un estudio de factibilidad. El estudio de factibilidad incluye un análisis de la factibilidad técnica, la viabilidad económica o asequibilidad, y la factibilidad legal. Este paso es importante para determinar si el proyecto debe ser iniciado y puede ser realizado por alguien con un título de Analista de Requisitos o Analista de Negocios
- Análisis de Sistemas. En esta fase uno o más analistas de sistemas trabajan con diferentes grupos de interés para determinar los requisitos específicos para el nuevo sistema. No se realiza programación en este paso. En cambio, se documentan los procedimientos, se entrevista a los jugadores/usuarios clave y se desarrollan los requisitos de datos para obtener una impresión general de exactamente lo que se supone que debe hacer el sistema. El resultado de esta fase es un documento de requisitos del sistema y puede ser realizado por alguien con título de Analista de Sistemas
- Diseño de Sistemas. En esta fase, un diseñador toma el documento de requisitos del sistema creado en la fase anterior y desarrolla los detalles técnicos específicos requeridos para el sistema. Es en esta fase que los requerimientos del negocio se traducen en requerimientos técnicos específicos. Aquí se desarrolla el diseño de la interfaz de usuario, la base de datos, las entradas y salidas de datos y la generación de informes. El resultado de esta fase es un documento de diseño del sistema. Este documento tendrá todo lo que un programador necesita para crear realmente el sistema y puede ser realizado por alguien con un título de Analista de Sistemas, Desarrollador o Arquitecto de Sistemas, basado en la escala del proyecto.
- Programación. El código finalmente se escribe en la fase de programación. Utilizando el documento de diseño del sistema como guía, los programadores desarrollan el software. El resultado de esta fase es un programa de trabajo inicial que cumple con los requisitos especificados en la fase de análisis del sistema y el diseño desarrollado en la fase de diseño del sistema. Estas tareas las realizan personas con títulos como Desarrollador, Ingeniero de Software, Programador o Codificador.
- Pruebas. En la fase de pruebas el programa de software desarrollado en la fase de programación se somete a una serie de pruebas estructuradas. La primera es una prueba unitaria, que evalúa partes individuales del código en busca de errores o errores. A esto le sigue una prueba del sistema en la que se prueban los diferentes componentes del sistema para garantizar que funcionen juntos correctamente. Por último, la prueba de aceptación del usuario permite a aquellos que estarán utilizando el software probar el sistema para asegurarse de que cumple con sus estándares. Cualquier error, error o problema encontrado durante las pruebas se resuelven y luego se vuelve a probar el software. Estas tareas las realizan personas con títulos como Tester, Analista de Pruebas o Aseguramiento de Calidad.
- Implementación. Una vez desarrollado y probado el nuevo sistema, tiene que ser implementado en la organización. Esta fase incluye la capacitación de los usuarios, el suministro de documentación y la conversión de datos del sistema anterior al nuevo sistema. La implementación puede tomar muchas formas, dependiendo del tipo de sistema, el número y tipo de usuarios, y cuán urgente es que el sistema entre en funcionamiento. Estas diferentes formas de implementación se tratan más adelante en el capítulo.
- Mantenimiento. Esta fase final se lleva a cabo una vez que se completa la fase de implementación. En la fase de mantenimiento el sistema cuenta con un proceso de soporte estructurado en su lugar. Se corrigen los errores reportados y se evalúan e implementan las solicitudes de nuevas funciones. Además, se realizan actualizaciones del sistema y copias de seguridad del software para cada nueva versión del programa. Dado que el mantenimiento es normalmente un Gasto Operativo (OPEX) mientras que gran parte del desarrollo es un Gasto de Capital (CAPEX), los fondos normalmente salen de diferentes presupuestos o centros de costos.
La metodología SDLC a veces se conoce como la metodología de cascada para representar cómo cada paso es una parte separada del proceso. Sólo cuando se completa un paso puede comenzar otro paso. Después de cada paso una organización debe decidir cuándo pasar al siguiente paso. Esta metodología ha sido criticada por ser bastante rígida, permitiendo el movimiento en una sola dirección, es decir, hacia adelante en el ciclo. Por ejemplo, no se permiten cambios en los requisitos una vez iniciado el proceso. No hay software disponible hasta después de la fase de programación.
Nuevamente, SDLC se desarrolló para proyectos grandes y estructurados. Los proyectos que utilizan SDLC a veces pueden tardar meses o años en completarse. Debido a su inflexibilidad y la disponibilidad de nuevas técnicas y herramientas de programación, se han desarrollado muchas otras metodologías de desarrollo de software. Muchos de estos conservan algunos de los conceptos subyacentes de SDLC, pero no son tan rígidos.
Desarrollo rápido de aplicaciones
El desarrollo rápido de aplicaciones (RAD) se enfoca en construir rápidamente un modelo de trabajo del software, obtener comentarios de los usuarios y luego usar esos comentarios para actualizar el modelo de trabajo. Después de varias iteraciones de desarrollo, se desarrolla e implementa una versión final.
La metodología RAD consta de cuatro fases.
- Planeación de Requisitos. Esta fase es similar a las fases de análisis preliminar, análisis de sistemas y diseño del SDLC. En esta fase se definen los requisitos generales para el sistema, se identifica un equipo y se determina la factibilidad.
- Diseño de Usuario. En la fase de diseño del usuario, los representantes de los usuarios trabajan con los analistas del sistema, diseñadores y programadores para crear interactivamente el diseño del sistema. En ocasiones se utiliza una sesión de Desarrollo de Aplicaciones Conjuntas (JAD) para facilitar el trabajo con todos estos diversos grupos de interés. Una sesión JAD reúne a todos los grupos de interés para una discusión estructurada sobre el diseño del sistema. Los desarrolladores de aplicaciones también participan y observan, tratando de entender la esencia de los requisitos.
- Construcción. En la fase de construcción los desarrolladores de aplicaciones, trabajando con los usuarios, construyen la siguiente versión del sistema a través de un proceso interactivo. Los cambios se pueden hacer a medida que los desarrolladores trabajan en el programa. Este paso se ejecuta en paralelo con el paso Diseño de Usuario de manera iterativa, realizando modificaciones hasta que se desarrolle una versión aceptable del producto.
- Cutover. El cambio implica cambiar del sistema antiguo al nuevo software. El tiempo de la fase de transición es crucial y generalmente se realiza cuando hay baja actividad. Por ejemplo, los sistemas de TI en la educación superior experimentan muchos cambios y actualizaciones durante el verano o entre el semestre de otoño y el semestre de primavera. Los enfoques de la migración del viejo al nuevo sistema varían entre organizaciones. Algunos prefieren simplemente iniciar el nuevo software y terminar el uso del software antiguo. Otros optan por usar un cambio incremental, poniendo una parte en línea a la vez. Un cambio a un nuevo sistema de contabilidad se puede hacer un módulo a la vez, como primero libro mayor general, luego nómina, seguido de cuentas por cobrar, etc. hasta que se hayan implementado todos los módulos. Un tercer enfoque es ejecutar los sistemas antiguos y nuevos en paralelo, comparando los resultados diariamente para confirmar que el nuevo sistema es preciso y confiable. Una discusión más profunda de las estrategias de implementación aparece cerca del final de este capítulo.
Como puede ver, la metodología RAD está mucho más comprimida que SDLC. Muchos de los pasos de SDLC se combinan y el enfoque está en la participación e iteración del usuario. Esta metodología es mucho más adecuada para proyectos más pequeños que SDLC y tiene la ventaja adicional de brindar a los usuarios la capacidad de proporcionar retroalimentación a lo largo del proceso. SDLC requiere más documentación y atención al detalle y se adapta bien a proyectos grandes y intensivos en recursos. RAD tiene más sentido para proyectos más pequeños que requieren menos recursos y necesitan desarrollarse rápidamente.
Metodologías ágiles
Las metodologías ágiles son un conjunto de metodologías que utilizan cambios incrementales con un enfoque en la calidad y la atención al detalle. Cada incremento se libera en un periodo de tiempo específico (llamado caja de tiempo), creando un calendario de lanzamiento regular con objetivos muy específicos. Si bien se considera una metodología separada de la RAD, las dos metodologías comparten algunos de los mismos principios, como el desarrollo iterativo, la interacción del usuario y la flexibilidad para cambiar. Las metodologías ágiles se basan en el “Manifiesto Ágil”, lanzado por primera vez en 2001.
Desarrollo ágil e iterativo
El diagrama anterior enfatiza las iteraciones en el centro del desarrollo ágil. Debes notar cómo los bloques de construcción del sistema en desarrollo se mueven de izquierda a derecha, un bloque a la vez, no todo el proyecto. Los bloques que no son aceptables se devuelven a través de comentarios y los desarrolladores realizan las modificaciones necesarias. Finalmente, observe la Revisión Diaria en la parte superior del diagrama. Desarrollo Ágil significa una evaluación constante tanto por parte de desarrolladores como de clientes (fíjese en el término “Colaboración”) del trabajo de cada día.
Las características de la metodología ágil incluyen:
- Pequeños equipos interfuncionales que incluyen miembros del equipo de desarrollo y usuarios;
- Reuniones diarias de estado para discutir el estado actual del proyecto;
- Incrementos cortos de plazos (de días a una o dos semanas) para cada cambio que se complete; y
- Proyecto de trabajo al final de cada iteración que demuestre avances a los grupos de interés.
El objetivo de las metodologías ágiles es proporcionar la flexibilidad de un enfoque iterativo al tiempo que se garantiza un producto de calidad.
Metodología Lean
Una última metodología a discutir es un concepto relativamente nuevo tomado del bestseller de negocios The Lean Startup de Eric Reis. Lean se enfoca en tomar una idea inicial y desarrollar un Producto Mínimo Viable (MVP). El MVP es una aplicación de software que funciona con la funcionalidad suficiente para demostrar la idea detrás del proyecto. Una vez desarrollado el MVP, el equipo de desarrollo lo entrega a usuarios potenciales para su revisión. La retroalimentación sobre el MVP se genera de dos formas. Primero, observación directa y discusión con los usuarios y segundo, estadísticas de uso recopiladas a partir del propio software. Usando estas dos formas de retroalimentación, el equipo determina si deben continuar en la misma dirección o repensar la idea central detrás del proyecto, cambiar las funciones y crear un nuevo MVP. Este cambio de estrategia se llama pivote. Se desarrollan varias iteraciones del MVP, con nuevas funciones agregadas cada vez en función de la retroalimentación, hasta completar un producto final.
La mayor diferencia entre las metodologías iterativas y no iterativas es que no se conoce el conjunto completo de requisitos para el sistema cuando se lanza el proyecto. A medida que se publica cada iteración del proyecto, las estadísticas y los comentarios recopilados se utilizan para determinar los requisitos. La metodología lean funciona mejor en un entorno emprendedor donde una empresa está interesada en determinar si vale la pena desarrollar su idea para un programa.
Sidebar: El Triángulo de Calidad
Al desarrollar software o cualquier tipo de producto o servicio, existe una tensión entre los desarrolladores y los diferentes grupos de interés como la gerencia, los usuarios y los inversionistas. Esta tensión se relaciona con la rapidez con la que se puede desarrollar el software (tiempo), cuánto dinero se gastará (costo) y qué tan bien se construirá (calidad). El triángulo de calidad es un concepto sencillo. Afirma que para cualquier producto o servicio que se esté desarrollando, sólo se pueden abordar dos de los siguientes: tiempo, costo y calidad.
Entonces, ¿por qué solo se pueden considerar dos de los tres factores en el triángulo? ¡Porque cada uno de estos tres componentes compiten entre sí! Si estás dispuesto y eres capaz de gastar mucho dinero, entonces un proyecto se puede completar rápidamente con resultados de alta calidad porque puedes aportar más recursos para su desarrollo. Si la fecha de finalización de un proyecto no es una prioridad, entonces se puede completar a un costo menor con resultados de mayor calidad utilizando un equipo más pequeño con menos recursos. Por supuesto, estas son solo generalizaciones, y es posible que diferentes proyectos no encajen perfectamente con este modelo. Pero en general, este modelo está diseñado para ayudarlo a comprender las compensaciones que deben hacerse cuando está desarrollando nuevos productos y servicios.
Hay otras razones fundamentales por las que los proyectos de bajo costo y alta calidad realizados rápidamente son tan difíciles de lograr.
- La mente humana es analógica y las máquinas en las que se ejecuta el software son digitales. Estas son naturalezas completamente diferentes que dependen del contexto y los matices versus ser un 1 o un 0. Las cosas que le parecen obvias a la mente humana no son tan obvias cuando se ven forzadas a una elección binaria de 1 o 0.
- Los seres humanos dejan sus huellas en las aplicaciones o sistemas que diseñan. Esto se resume mejor en la Ley de Conway (1968) — “Las organizaciones que diseñan sistemas de información están obligadas a hacerlo de una manera que refleja sus procesos internos de comunicación”. A las organizaciones con malos procesos de comunicación les resultará muy difícil comunicar requisitos y prioridades, especialmente para proyectos a nivel empresarial (es decir, que afectan a toda la organización.
Lenguajes de Programación
Como se señaló anteriormente, los desarrolladores crean programas utilizando uno de varios lenguajes de programación. Un lenguaje de programación es un lenguaje artificial que proporciona una forma para que un desarrollador cree código de programación para comunicar la lógica en un formato que puede ser ejecutado por el hardware de la computadora. En las últimas décadas, muchos tipos diferentes de lenguajes de programación han evolucionado para satisfacer una variedad de necesidades. Una forma de caracterizar los lenguajes de programación es por su “generación”.
Generaciones de lenguajes de programación
Los primeros lenguajes eran específicos del tipo de hardware que había que programar. Cada tipo de hardware de computadora tenía un lenguaje de programación de bajo nivel diferente. En esos primeros idiomas hubo que introducir instrucciones muy específicas línea por línea, un proceso tedioso.
Los lenguajes de primera generación se llamaban código de máquina porque la programación se hacía en el formato que la máquina/computadora podía leer. Así que la programación se realizó configurando directamente unos y ceros reales (los bits) en el programa usando código binario. Aquí hay un programa de ejemplo que agrega 1234 y 4321 usando el lenguaje de la máquina:
10111001 00000000 11010010 10100001 00000100 00000000 10001001 00000000 00001110 10001011 00000000 00011110 00000000 00011110 00000000 00000010 10111001 00000000 11100001 00000011 00010000 11000011 10001001 10100011 00001110 00000100 00000010 00000000
El lenguaje ensamblador es el idioma de segunda generación y usa frases similares al inglés en lugar de instrucciones de código automático, lo que facilita la programación. Un programa de lenguaje ensamblador debe ejecutarse a través de un ensamblador, que lo convierte en código de máquina. Aquí hay un programa de muestra que agrega 1234 y 4321 usando lenguaje ensamblador.
MOV CX,1234 MOV DS:[0],CX MOV CX,4321 MOV AX,DS:[0] MOV BX,DS:[2] ADD AX,BX MOV DS:[4],AX
Los lenguajes de tercera generación no son específicos del tipo de hardware en el que se ejecutan y son similares a los idiomas hablados. La mayoría de los lenguajes de tercera generación deben ser compilados. El desarrollador escribe el programa en una forma conocida genéricamente como código fuente, luego el compilador convierte el código fuente en código máquina, produciendo un archivo ejecutable. Los lenguajes conocidos de tercera generación incluyen BASIC, C, Python y Java. Aquí hay un ejemplo usando BASIC:
A=1234 B=4321 C=A+B END
Los lenguajes de cuarta generación son una clase de herramientas de programación que permiten el desarrollo rápido de aplicaciones mediante interfaces y entornos intuitivos. Muchas veces un lenguaje de cuarta generación tiene un propósito muy específico, como la interacción con bases de datos o la redacción de informes. Estas herramientas pueden ser utilizadas por aquellos con muy poca formación formal en programación y permiten el rápido desarrollo de aplicaciones y/o funcionalidad. Ejemplos de lenguajes de cuarta generación incluyen: Clipper, FOCUS, SQL y SPSS.
¿Por qué alguien querría programar en un idioma de nivel inferior cuando requieren tanto más trabajo? La respuesta es similar a por qué algunos prefieren conducir vehículos de transmisión manual en lugar de transmisión automática, es decir, control y eficiencia. Los lenguajes de nivel inferior, como el lenguaje ensamblador, son mucho más eficientes y se ejecutan mucho más rápidamente. El desarrollador también tiene un control más fino sobre el hardware. A veces se mezcla una combinación de lenguajes de nivel superior e inferior para obtener lo mejor de ambos mundos. El programador puede crear la estructura general y la interfaz usando un lenguaje de nivel superior pero usar lenguajes de nivel inferior para las partes del programa que se usan muchas veces, requieren más precisión o necesitan mayor velocidad.
Compilado vs. interpretado
Además de identificar un lenguaje de programación basado en su generación, también podemos clasificarlo a través de la distinción de si es compilado o interpretado. Un lenguaje informático está escrito en una forma legible por humanos. En un lenguaje compilado el código del programa se traduce a una forma legible por máquina llamada ejecutable que se puede ejecutar en el hardware. Algunos lenguajes compilados conocidos incluyen C, C++ y COBOL.
Los lenguajes interpretados requieren que se instale un programa en tiempo de ejecución para poder ejecutarse. Cada vez que el usuario quiere ejecutar el software, el programa de tiempo de ejecución debe interpretar el código del programa línea por línea y luego ejecutarlo. Los lenguajes interpretados son generalmente más fáciles de trabajar, pero también son más lentos y requieren más recursos del sistema. Ejemplos de lenguajes interpretados populares incluyen BASIC, PHP, PERL y Python. Los lenguajes web de HTML y JavaScript también se consideran interpretados porque requieren de un navegador para poder ejecutarse.
El lenguaje de programación Java es una interesante excepción a esta clasificación, ya que en realidad es un híbrido de los dos. Un programa escrito en Java se compila parcialmente para crear un programa que pueda ser entendido por la Máquina Virtual Java (JVM). Cada tipo de sistema operativo tiene su propia JVM que debe ser instalada antes de que cualquier programa pueda ser ejecutado. El enfoque JVM permite que un solo programa Java se ejecute en muchos tipos diferentes de sistemas operativos.
Procesal vs. orientado a objetos
Un lenguaje de programación procedimental está diseñado para permitir que un programador defina un punto de partida específico para el programa y luego ejecutarlo secuencialmente. Todos los lenguajes de programación tempranos funcionaban de esta manera. A medida que las interfaces de usuario se volvieron más interactivas y gráficas, tenía sentido que los lenguajes de programación evolucionaran para permitir que el usuario tuviera un mayor control sobre el flujo del programa. Un lenguaje de programación orientado a objetos está diseñado para que el programador defina “objetos” que puedan tomar ciertas acciones en función de la entrada del usuario. En otras palabras, un programa procedimental se enfoca en la secuencia de actividades a realizar mientras que un programa orientado a objetos se enfoca en los diferentes ítems que se manipulan.
Considerar un sistema de recursos humanos donde se necesitaría un objeto “EMPLEADO”. Si el programa necesitaba recuperar o establecer datos con respecto a un empleado, primero crearía un objeto empleado en el programa y luego establecería o recuperaría los valores necesarios. Cada objeto tiene propiedades, que son campos descriptivos asociados al objeto. También conocido como Esquema, es la vista lógica del objeto (es decir, cada fila de propiedades representa una columna en la tabla real, que se conoce como la vista física). El objeto employee tiene las propiedades “EMPLEEID”, “FIRSTNAME”, “LASTNAME”, “NACHTDATE” y “HIREDATE”. Un objeto también tiene métodos que pueden tomar acciones relacionadas con el objeto. Hay dos métodos en el ejemplo. El primero es “ADDEMPLOYEE ()”, que creará otro registro de empleado. El segundo es “EDITEMPLOYEE ()” que modificará los datos de un empleado.
Herramientas de Programación
Para escribir un programa, se necesita poco más que un editor de texto y una buena idea. No obstante, para ser productivo se debe poder comprobar la sintaxis del código, y, en algunos casos, compilar el código. Para ser más eficientes en la programación, se pueden utilizar herramientas adicionales, como un Entorno de Desarrollo Integrado (IDE) o herramientas de ingeniería de software asistida por computadora (CASE).
Entorno de Desarrollo Integrado
Para la mayoría de los lenguajes de programación se puede utilizar un Entorno de Desarrollo Integrado (IDE) para desarrollar el programa. Un IDE proporciona una variedad de herramientas para el programador, y generalmente incluye:
- Editor. Se utiliza un editor para escribir el programa. Los comandos son codificados por colores automáticamente por el IDE para identificar los tipos de comandos. Por ejemplo, un comentario de programación podría aparecer en verde y una instrucción de programación podría aparecer en negro.
- Sistema de ayuda. Un sistema de ayuda brinda documentación detallada sobre el lenguaje de programación.
- Compilador/intérprete. El compilador/intérprete convierte el código fuente del programador en lenguaje de máquina para que pueda ser ejecutado/ejecutado en la computadora.
- Herramienta de depuración. La depuración ayuda al desarrollador a localizar errores y encontrar soluciones.
- Mecanismo de entrada y salida. Esta herramienta permite a equipos de programadores trabajar simultáneamente en un programa sin sobrescribir el código de otro programador.
Ejemplos de IDE incluyen Visual Studio de Microsoft y Eclipse de Oracle. Visual Studio es el IDE para todos los lenguajes de programación de Microsoft, incluidos Visual Basic, Visual C++ y Visual C#. Eclipse se puede utilizar para Java, C, C++, Perl, Python, R y muchos otros lenguajes.
Herramientas CASE
Si bien un IDE proporciona varias herramientas para ayudar al programador a escribir el programa, el código aún debe escribirse. Las herramientas de Ingeniería de Software Asistida por Computadora (CASE) permiten a un diseñador desarrollar software con poca o ninguna programación. En cambio, la herramienta CASE escribe el código para el diseñador. Las herramientas CASE vienen en muchas variedades. Su objetivo es generar código de calidad basado en la entrada creada por el diseñador.
Barra lateral: Construyendo un sitio web
En los primeros días de la World Wide Web, la creación de un sitio web requería saber usar HyperText Markup Language (HTML). Hoy en día la mayoría de los sitios web están construidos con una variedad de herramientas, pero el producto final que se transmite a un navegador sigue siendo HTML. En su forma más simple HTML es un lenguaje de texto que permite definir los diferentes componentes de una página web. Estas definiciones se manejan mediante el uso de etiquetas HTML con texto entre las etiquetas o corchetes. Por ejemplo, una etiqueta HTML puede indicar al navegador que muestre una palabra en cursiva, que se vincule a otra página web o que inserte una imagen. El siguiente código HTML selecciona dos tipos diferentes de encabezados (h1 y h2) con texto debajo de cada encabezado. Parte del texto ha sido cursiva. La salida tal como aparecería en un navegador se muestra después del código HTML.
<h1>This is a first-level heading</h1> Here is some text. <em>Here is some emphasized text.</em> <h2>Here is a second-level heading</h2) Here is some more text.
Código HTML
Mientras que HTML se utiliza para definir los componentes de una página web, las hojas de estilo en cascada (CSS) se utilizan para definir los estilos de los componentes en una página. El uso de CSS permite que se establezca el estilo de un sitio web y se mantenga constante en todo momento. Por ejemplo, un diseñador que quería que todos los encabezados de primer nivel (h1) fueran azules y centrados podría establecer el estilo “h1″ para que coincida. El siguiente ejemplo muestra cómo podría verse esto.
<style> h1 { color:blue; text-align:center; } </style> <h1>This is a first-level heading</h1> Here is some text. <em>Here is some emphasized text.</em> <h2>Here is a second-level heading</h2) Here is some more text.
Código HTML con CSS agregado
La combinación de HTML y CSS se puede utilizar para crear una amplia variedad de formatos y diseños y ha sido ampliamente adoptada por la comunidad de diseño web. Los estándares para HTML son establecidos por un órgano de gobierno llamado World Wide Web Consortium. La versión actual de HTML 5 incluye nuevos estándares para video, audio y dibujo.
Cuando los desarrolladores crean un sitio web, no lo escriben manualmente en un editor de texto. En cambio, utilizan herramientas de diseño web que generan el HTML y CSS para ellos. Herramientas como Adobe Dreamweaver permiten al diseñador crear una página web que incluya imágenes y elementos interactivos sin escribir una sola línea de código. Sin embargo, los diseñadores web profesionales aún necesitan aprender HTML y CSS para tener un control total sobre las páginas web que están desarrollando.
Barra lateral: Construyendo una aplicación móvil
En muchos sentidos, construir una aplicación para un dispositivo móvil es exactamente lo mismo que construir una aplicación para una computadora tradicional. Comprender los requisitos para la aplicación, diseñar la interfaz y trabajar con los usuarios son todos los pasos que aún deben llevarse a cabo.
Aplicaciones Móviles
Entonces, ¿qué tiene de diferente construir una aplicación para un dispositivo móvil? Hay cinco diferencias principales:
- Avances en tecnologías de componentes. Los dispositivos móviles requieren múltiples componentes que no solo son más pequeños sino más eficientes energéticamente que los de las computadoras de tamaño completo (laptops o computadoras de escritorio). Por ejemplo, las CPU de bajo consumo combinadas con baterías de mayor duración, pantallas táctiles y Wi-Fi permiten una computación muy eficiente en un teléfono, que necesita hacer mucho menos procesamiento real que sus contrapartes de tamaño completo.
- Los sensores han desbloqueado la noción de contexto. La combinación de sensores como GPS, giroscopios y cámaras permite que los dispositivos sean conscientes de cosas como el tiempo, la ubicación, la velocidad, la dirección, la altitud, la actitud y la temperatura. La ubicación en particular brinda una gran cantidad de beneficios.
- Las aplicaciones simples, especialmente diseñadas y orientadas a tareas son fáciles de usar. Las aplicaciones móviles tienen un alcance mucho más limitado que el software empresarial y, por tanto, son más fáciles de usar. De igual manera, necesitan ser intuitivos y no requerir ningún entrenamiento.
- El acceso inmediato a los datos extiende la propuesta de valor. Además de que la aplicación proporciona una interfaz más simple en el front-end, los servicios de datos basados en la nube brindan acceso a los datos casi en tiempo real, desde prácticamente cualquier lugar (por ejemplo, banca, viajes, direcciones de manejo e inversión). Tener acceso a la nube es necesario para mantener el tamaño del dispositivo móvil y el uso de energía bajos.
- Las tiendas de aplicaciones han simplificado la adquisición. El desarrollo, la adquisición y la administración de aplicaciones han sido revolucionados por las tiendas de aplicaciones como la App Store de Apple y Google Play. Los procesos de desarrollo estandarizados y los requisitos de las aplicaciones permiten a los desarrolladores externos a Apple y Google crear nuevas aplicaciones con un canal de distribución integrado. Los bajos precios promedio de las aplicaciones (incluidos muchos de los cuales son gratuitos) han alimentado la demanda.
En resumen, las diferencias entre construir una aplicación móvil y otros tipos de desarrollo de software se ven así:
La construcción de una aplicación móvil para sistemas operativos iOS y Android se conoce como desarrollo multiplataforma. Hay una serie de kits de herramientas de terceros disponibles para crear tu aplicación. Muchos convertirán código existente como HTML5, JavaScript, Ruby, C++, etc. Sin embargo, si tu app requiere una programación sofisticada, es posible que un kit de desarrollador multiplataforma no satisfaga tus necesidades.
Responsive Web Design (RWD) se enfoca en hacer que las páginas web se rendericen bien en todos los dispositivos: escritorio, computadora portátil, tableta, teléfono inteligente. A través del concepto de diseño fluido RWD ajusta automáticamente el contenido al dispositivo en el que se está visualizando. Puedes encontrar más información sobre el diseño responsive aquí.
Construir vs. Comprar
Cuando una organización decide que es necesario desarrollar un nuevo programa, debe determinar si tiene más sentido construirlo ellos mismos o comprarlo a una compañía externa. Esta es la decisión de “construir vs. comprar”.
La compra de software de una compañía externa tiene muchas ventajas. Primero, generalmente es menos costoso comprar software que construirlo. En segundo lugar, cuando se compra software, está disponible mucho más rápidamente que si el paquete se construye internamente. El software puede tardar meses o años en construirse. Un paquete comprado puede estar listo y funcionando dentro de unos días. Tercero, ya se ha probado un paquete comprado y muchos de los errores ya se han resuelto. Es el papel de un integrador de sistemas hacer que varios sistemas comprados y los sistemas existentes en la organización trabajen juntos.
También hay desventajas en la compra de software. Primero, el mismo software que estás usando puede ser utilizado por tus competidores. Si una empresa está tratando de diferenciarse en función de un proceso de negocio incorporado al software adquirido, tendrá dificultades para hacerlo si sus competidores utilizan el mismo software. Otra desventaja de la compra de software es el proceso de personalización. Si compra software de un proveedor y luego lo personaliza, tendrá que administrar esas personalizaciones cada vez que el proveedor proporcione una actualización. Esto puede convertirse en un dolor de cabeza administrativo, por decir lo menos.
Incluso si una organización determina comprar software, todavía tiene sentido pasar por el mismo análisis que si se iba a desarrollar. Esta es una decisión importante que podría tener un impacto estratégico a largo plazo en la organización.
Servicios Web
En el capítulo 3 se discutió cómo el paso a la computación en la nube ha permitido que el software sea visto como un servicio. Una opción, conocida como servicios web, permite a las empresas licenciar funciones proporcionadas por otras empresas en lugar de escribir el código ellas mismas. Los servicios web pueden simplificar enormemente la adición de funcionalidad a un sitio web.
Supongamos que una empresa desea proporcionar un mapa que muestre la ubicación de alguien que ha llamado a su línea de soporte. Al utilizar los servicios web de la API de Google Maps, la compañía puede crear un Google Map directamente en su aplicación. O una compañía de calzado podría facilitar a sus minoristas vender zapatos en línea al proporcionar un servicio web de tallado de zapatos que los minoristas podrían incrustar directamente en su sitio web.
Los servicios web pueden difuminar las líneas entre “construir vs. comprar”. Las empresas pueden optar por crear una aplicación por sí mismas, pero luego comprar la funcionalidad de los proveedores para complementar su sistema.
Computación para el usuario final (EUC)
En muchas organizaciones el desarrollo de aplicaciones no se limita a los programadores y analistas del departamento de tecnología de la información. Especialmente en organizaciones más grandes, otros departamentos desarrollan sus propias aplicaciones específicas de departamento. Las personas que construyen estas aplicaciones no están necesariamente capacitadas en programación o desarrollo de aplicaciones, sino que tienden a ser adeptos con las computadoras. Una persona experta en un programa en particular, como una hoja de cálculo o paquete de base de datos, puede ser llamada a construir aplicaciones más pequeñas para su uso por su propio departamento. Este fenómeno se conoce como desarrollo de usuario final, o computación de usuario final.
La computación del usuario final puede tener muchas ventajas para una organización. Primero, acerca el desarrollo de aplicaciones a quienes las usarán. Debido a que los departamentos de TI a veces están atrasados, también proporciona un medio para que el software se cree más rápidamente. Muchas organizaciones fomentan la computación del usuario final para reducir la tensión en el departamento de TI.
La computación del usuario final también tiene sus desventajas. Si los departamentos dentro de una organización están desarrollando sus propias aplicaciones, la organización puede terminar con varias aplicaciones que realizan funciones similares, lo cual es ineficiente, ya que se trata de una duplicación de esfuerzos. En ocasiones estas diferentes versiones de una misma aplicación terminan proporcionando resultados diferentes, trayendo confusión cuando los departamentos interactúan. Las aplicaciones de usuario final suelen ser desarrolladas por alguien con poca o ninguna formación formal en programación. En estos casos, el software desarrollado puede tener problemas que luego tienen que ser resueltos por el departamento de TI.
La computación del usuario final puede ser beneficiosa para una organización siempre que se administre. El departamento de TI debe establecer pautas y proporcionar herramientas para los departamentos que quieran crear sus propias soluciones. La comunicación entre departamentos puede recorrer un largo camino hacia el uso exitoso de la computación del usuario final.
Sidebar: Riesgos de EUC como “Shadow IT”
La Compañía Federal Hipotecaria de Préstamos para el Hogar, mejor conocida como Freddie Mac, fue multada con más de 100 millones de dólares en 2003 en parte por subestimar sus ganancias. Esto desencadenó un proyecto a gran escala para reafirmar sus finanzas, lo que implicó automatizar la información financiera para cumplir con la Ley Sarbanes-Oxley de 2002. Parte del proyecto de reformulación encontró que los EUC (como hojas de cálculo y bases de datos en computadoras portátiles individuales) estaban ingresando al Libro Mayor. Si bien los EUC no fueron la causa de los problemas de Freddie Mac (fueron un síntoma de una supervisión insuficiente) para tener una gobernanza de TI tan pobre en una empresa tan grande fue un problema grave. Resulta que estos EUC se hicieron en parte para agilizar el tiempo que tardó en realizar cambios en sus procesos de negocio (una queja común de los departamentos de TI en las grandes corporaciones es que lleva demasiado tiempo hacer las cosas). Como tal, estos EUC sirvieron como una forma de “TI en la sombra” que no había pasado por un proceso de pruebas riguroso normal.
Metodologías de implementación
Una vez desarrollado o adquirido un nuevo sistema, la organización debe determinar el mejor método para su implementación. Convencer a un grupo de personas para que aprendan y utilicen un nuevo sistema puede ser un proceso muy difícil. Pedir a los empleados que usen nuevo software así como seguir un nuevo proceso de negocio puede tener efectos de largo alcance dentro de la organización.
Existen varias metodologías diferentes que una organización puede adoptar para implementar un nuevo sistema. Cuatro de los más populares se enumeran a continuación.
- Corte directo. En la metodología de implementación de transición directa, la organización selecciona una fecha particular para terminar el uso del sistema antiguo. En esa fecha los usuarios comienzan a usar el nuevo sistema y el sistema antiguo no está disponible. El corte directo tiene la ventaja de ser muy rápido y el método de implementación menos costoso. Sin embargo, este método tiene el mayor riesgo. Si el nuevo sistema tiene un problema operativo o si los usuarios no están debidamente preparados, podría resultar desastroso para la organización.
- Implementación piloto. En esta metodología un subconjunto de la organización conocida como grupo piloto comienza a utilizar el nuevo sistema antes que el resto de la organización. Esto tiene un menor impacto en la empresa y permite que el equipo de soporte se centre en un grupo más pequeño de individuos. Además, los problemas con el nuevo software pueden ser contenidos dentro del grupo y luego resolverse.
- Operación paralela. Las operaciones paralelas permiten que tanto los sistemas antiguos como los nuevos sean utilizados simultáneamente por un período de tiempo limitado. Este método es el menos riesgoso porque el viejo sistema todavía se está utilizando mientras que el nuevo sistema esencialmente se está probando. Sin embargo, esta es, con mucho, la metodología más cara ya que se duplica el trabajo y se necesita soporte para ambos sistemas en su totalidad.
- Implementación por fases. La implementación por fases permite que diferentes funciones de la nueva aplicación se implementen gradualmente con las funciones correspondientes apagadas en el sistema antiguo. Este enfoque es más conservador ya que permite que una organización se mueva lentamente de un sistema a otro.
Su elección de una metodología de implementación depende de la complejidad de los sistemas antiguos y nuevos. También depende del grado de riesgo que estés dispuesto a correr.
Gestión del Cambio
A medida que los nuevos sistemas se ponen en línea y los sistemas antiguos se van eliminando gradualmente, se vuelve importante administrar la forma en que se implementa el cambio en la organización. El cambio nunca debe introducirse en el vacío. La organización debe asegurarse de comunicar los cambios propuestos antes de que ocurran y planear minimizar el impacto del cambio que ocurrirá después de la implementación. La gestión del cambio es un componente crítico de la supervisión de TI.
Barra lateral: mal manejo del cambio
Target Corporation, que opera más de 1,500 tiendas de descuento en todo Estados Unidos, abrió 133 tiendas similares en Canadá entre 2013 y 2015. La compañía decidió implementar un nuevo sistema de Planificación de Recursos Empresariales (ERP) que integraría datos de proveedores, clientes y realizaría cálculos de divisas (dólares estadounidenses y dólares canadienses). Esta implementación coincidió con el agresivo plan de expansión de Target Canada y la dura competencia de Wal-Mart. Un cronograma de dos años, agresivo según cualquier estándar para una implementación de este tamaño, no tuvo en cuenta los errores de datos de múltiples fuentes que resultaron en recuentos de inventario erróneos y cálculos financieros. Su cadena de suministro se volvió caótica y las tiendas estaban plagadas de no tener suficientes existencias de artículos comunes, lo que impidió la ventaja clave de “ventanilla única” para los clientes. A principios de 2015, Target Canada anunció que cerraría las 133 tiendas. En suma, “Esta implementación rompió casi todos los pecados cardinales de los proyectos ERP. Target estableció metas poco realistas, no dejó tiempo para las pruebas y descuidó capacitar a los empleados adecuadamente”. [1]
Mantenimiento
Después de que se ha introducido un nuevo sistema, entra en la fase de mantenimiento. El sistema está en producción y está siendo utilizado por la organización. Si bien el sistema ya no se está desarrollando activamente, es necesario realizar cambios cuando se encuentran errores o se solicitan nuevas funciones. Durante la fase de mantenimiento, la administración de TI debe garantizar que el sistema continúe alineado con las prioridades del negocio y continúe funcionando bien.
Resumen
El desarrollo de software es mucho más que programación. Se trata fundamentalmente de resolver problemas de negocios. El desarrollo de nuevas aplicaciones de software requiere de varios pasos, desde el proceso formal de SDLC hasta procesos más informales como la programación ágil o las metodologías lean. Los lenguajes de programación han evolucionado desde lenguajes específicos de máquina de muy bajo nivel hasta lenguajes de nivel superior que permiten a un programador escribir software para una amplia variedad de máquinas. La mayoría de los programadores trabajan con herramientas de desarrollo de software que les proporcionan componentes integrados para hacer que el proceso de desarrollo de software sea más eficiente. Para algunas organizaciones, construir su propio software no tiene más sentido. En cambio, optan por comprar software creado por un tercero para ahorrar costos de desarrollo y acelerar la implementación. En la computación del usuario final, el desarrollo de software ocurre fuera del departamento de tecnología de la información Al implementar nuevas aplicaciones de software, existen varios tipos diferentes de metodologías de implementación que deben ser consideradas.
Preguntas de Estudio
- ¿Cuáles son los pasos en la metodología SDLC?
- ¿Qué es el desarrollo de software RAD?
- ¿Qué hace que la metodología lean sea única?
- ¿Cuáles son las tres diferencias entre los idiomas de segunda generación y tercera generación?
- ¿Por qué una organización consideraría construir su propia aplicación de software si es más económico comprarla?
- ¿Qué es el diseño responsive?
- ¿Cuál es la relación entre HTML y CSS en el diseño de sitios web?
- ¿Cuál es la diferencia entre la metodología de implementación piloto y la metodología de implementación paralela?
- ¿Qué es la gestión del cambio?
- ¿Cuáles son las cuatro metodologías de implementación diferentes?
Ejercicios
- ¿Qué metodología de desarrollo de software sería mejor si una organización necesitara desarrollar una herramienta de software para un pequeño grupo de usuarios en el departamento de marketing? ¿Por qué? ¿Qué metodología de implementación deberían utilizar? ¿Por qué?
- Haciendo tu propia investigación, encuentra tres lenguajes de programación y categorizalos en estas áreas: generación, compilado vs. interpretado, procesal vs. orientado a objetos.
- Algunos argumentan que HTML no es un lenguaje de programación. Haciendo tu propia investigación, encuentra tres argumentos de por qué no es un lenguaje de programación y tres argumentos para por qué lo es.
- Lee más sobre el diseño responsivo usando el enlace dado en el texto. Proporcione los enlaces a tres sitios web que utilicen el diseño responsive y explique cómo demuestran el comportamiento de diseño responsivo.
Laboratorios
1. Aquí tienes un programa Python para que lo analices. El siguiente código trata sobre el peso y la estatura de una persona. Vea si puede adivinar qué se imprimirá y luego intente ejecutar el código en un intérprete de Python como https://www.onlinegdb.com/online_python_interpreter.
measurements = (8, 20) print("Original measurements:") for measurement in measurements: print(measurement) measurements = (170, 72) print("\nModified measurements:") for measurement in measurements: print(measurement)
2. Aquí tienes un programa Java roto para que lo analices. El siguiente código trata del cálculo de la matrícula, multiplicando la tasa de matrícula y el número de créditos tomados. El número de créditos es ingresado por el usuario del programa. El siguiente código está roto y da la respuesta incorrecta. Revise el problema a continuación y determine cuál sería la salida si el usuario ingresara “6” para el número de créditos. ¿Cómo arreglarías el programa para que diera la salida correcta?
package calcTuition; //import Scanner import java.util.Scanner; public class CalcTuition { public static void main(String[] args) { //Declare variables int credits; final double TUITION_RATE = 100; double tuitionTotal; //Get user input Scanner inputDevice = new Scanner(System.in); System.out.println("Enter the number of credits: "); credits = inputDevice.nextInt(); //Calculate tuition tuitionTotal = credits + TUITION_RATE; //Display tuition total System.out.println("You total tuition is: " + tuitionTotal); } }
- Tomado de ACC Software Solutions. “LAS MUCHAS CARAS DE LAS IMPLEMPLACIONES DE ERP FALLADAS (Y CÓMO EVITAR https://4acc.com/article/failed-erp-implementations/