ISW II Semana 6 PDF

También podría gustarte

Está en la página 1de 7

ISI – INGENIERÍA DE SOFTWARE II 2019-II

SEMANA 6: DISEÑO Y CONSTRUCCIÓN DE SOFTWARE

Desarrollar un software significa construirlo simplemente mediante su descripción. Esta es


una muy buena razón para considerar la actividad de desarrollo de software como una
ingeniería. En un nivel más general, la relación existente entre un software y su entorno es
clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos en
el mismo.

Aquellas partes del mundo que afectarán al software y que serán afectadas por él será el
Dominio de Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo del
software ha cumplido su propósito. Una de las mayores deficiencias en la práctica de
construcción de software es la poca atención que se presta a la discusión del problema. En
general los desarrolladores se centran en la solución dejando el problema inexplorado. El
problema a resolver debe ser deducido a partir de su solución.

Esta aproximación orientada a la solución puede funcionar en campos donde todos los
problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en la
detección de nuevas soluciones a viejos problemas. Pero el desarrollo de software no es un
campo con tales características. La versatilidad de las computadoras y su rápida evolución
hace que exista un repertorio de problemas en constante cambio y cuya solución software sea
de enorme importancia.

Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente que


es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el
Analista de Sistema que es el encargado de hacerle llegar todos los requerimientos y
necesidades que tiene el cliente a los programadores que son las personas encargadas de
realizar lo que es la codificación y diseño del sistema para después probarlo y lo instalan al
cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar
todo lo necesario lo más seguro que le haga falta algún requerimiento o alguna parte del
nuevo sistema y entre más estén involucradas mejor para cubrir con todos los requerimientos
del sistema.

I. FASES DEL PROCESO DE DESARROLLO DE SOFTWARE


Análisis de requerimientos:
Extraer los requisitos de un producto de software es la primera etapa para crearlo.
Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se
requiere de habilidad y experiencia en la ingeniería de software para reconocer
requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de
requisitos con el cliente se plasma en el documento ERS, Especificación de
Requerimientos del Sistema, cuya estructura puede venir definida por varios
estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación,

MSc. Ing. Wilfredo M. Trejo F. 1


ISI – INGENIERÍA DE SOFTWARE II 2019-II

en el que se plasman las principales entidades que participarán en el desarrollo del


software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos),
es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos
finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque
aún no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-
1998 normaliza la creación de las Especificaciones de Requisitos Software (Software
Requirements Specification).

Diseño y arquitectura:
Se refiere a determinar cómo funcionará de forma general sin entrar en detalles.
Consiste en incorporar consideraciones de la implementación tecnológica, como el
hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará
el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases
de diseño, obteniendo un modelo cercano a la programación orientada a objetos.

Programación:
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de
software, pero no es necesariamente la porción más larga. La complejidad y la duración
de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados.

Pruebas:
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificación. Una técnica de prueba es probar por separado cada módulo del
software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera
una buena práctica el que las pruebas sean efectuadas por alguien distinto al
desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo
anterior el programador debe hacer sus propias pruebas. En general hay dos grandes
formas de organizar un área de pruebas, la primera es que esté compuesta por personal
inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la
documentación]entregada sea de calidad, que los procesos descritos son tan claros que
cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El
segundo enfoque es tener un área de pruebas conformada por programadores con
experiencia, personas que saben sin mayores indicaciones en que condiciones puede
fallar una aplicación y que pueden poner atención en detalles que personal inexperto
no consideraría.

Documentación:
Todo lo concerniente a la documentación del propio desarrollo del software y de la
gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales
de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones,
usabilidad, mantenimiento futuro y ampliaciones al sistema.

MSc. Ing. Wilfredo M. Trejo F. 2


ISI – INGENIERÍA DE SOFTWARE II 2019-II

Mantenimiento:
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.
Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor
de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una
pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte
consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor
de 2/3 de toda la Ingeniería civil, Arquitectura y trabajo de construcción es dar
mantenimiento.

Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el
estarla aplicando día con día es la mejor decisión que puede llegar a tener cualquier
empresa, porque de esta manera evita grandes problemas en la elaboración o desarrollo
de los productos. Esto es fundamental para todas las empresas ya que se vuelven
competitivas, con mayor productividad y eficiencia. No hay que olvidar que la mejora
se da porque el cliente es el rey y hay que satisfacer todas y cada una de sus necesidades
siempre garantizando la calidad.

II. METODOLOGÍA
Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una
metodología de por medio, se obtiene clientes insatisfechos con el resultado y
desarrolladores aún más. Sin embargo, muchas veces no se toma en cuenta el utilizar
una metodología adecuada, sobre todo cuando se trata de proyectos pequeños de dos o
tres meses.

Con relación a los proyectos que se desarrollan con mayor envergadura, hay si se toma
el sentido de basarse en una metodología de desarrollo y se empieza a buscar cuál sería
la más apropiada para dicho caso. A fin de cuenta no encontramos muchas veces la más
adecuada y se termina por hacer un diseño propio de metodología, por supuesto no está
mal siempre y cuando sirva para alcanzar el objetivo.

Muchas veces se realiza el diseño del software de manera rígida, tal como el cliente lo
solicitó, de esa manera cuando el cliente en la "etapa de prueba" solicita un cambio se
hace muy difícil de realizarlo, pues si se hace altera las cosas que no se habían previsto,
y este es uno de los factores que atrasan el proyecto y crea incomodidad al desarrollador
y en muchas oportunidades no llegan a cumplir con el cambio solicitado, esto conlleva
malestar en el cliente puesto que no ha sido tomado en cuenta su pedido; para evitar
estos incidentes se debe llegar a un acuerdo formal con el cliente al inicio del proyecto
de manera que no perjudique el desarrollo del mismo. Muchas veces los usuarios
finales se dan cuenta que dejaron de mencionar algunas cosas y lo manifiestan en la
etapa inicial del proyecto cuando se le muestra el prototipo del mismo.

MSc. Ing. Wilfredo M. Trejo F. 3


ISI – INGENIERÍA DE SOFTWARE II 2019-II

Algunas Metodologías conocidas:


✓ La metodología RUP es la más adaptable para proyectos de largo plazo.
✓ La metodología XP en cambio, se recomienda para proyectos de corto plazo.
✓ La metodología MSF (Microsoft Solutions Framework) se adapta a proyectos
de cualquier dimensión y de cualquier tecnología.
Se puede decir además que lo más importante antes de elegir la metodología que se
debe usar para implementar el software, es determinar el alcance que tendrá y luego de
allí ver cuál es la que más se acomoda a la aplicación.

III. ARQUITECTURA DE SOFTWARE


La arquitectura de software es un conjunto de patrones que proporcionan un marco de
referencia necesario para guiar la construcción de un software, permitiendo a los
programadores, analistas y todo el conjunto de desarrolladores del software compartir
una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación.
Es considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto
que establecen la estructura, funcionamiento e interacción entre las partes del software.

Componentes:
La arquitectura de software se compone por:
✓ Clientes y servidores.
✓ Bases de datos.
✓ Filtros.
✓ Niveles en sistemas jerárquico.

Interacciones:
Entre los componentes de la arquitectura de software existe un conjunto de
interacciones entre las que sobresalen:
✓ Llamadas a procedimientos.
✓ Comportamiento de variables.
✓ Protocolos cliente servidor.
✓ Transmisión asíncrona de eventos.

La arquitectura de software forma la columna vertebral para construir un sistema de


software, es en gran medida responsable de permitir o no ciertos atributos de calidad
del sistema entre los que se destacan la confiabilidad y el rendimiento del software.
Además es un modelo abstracto reutilizable que puede transferirse de un sistema a otro
y que representa un medio de comunicación y discusión entre participantes del
proyecto, permitiendo así la interacción e intercambio entre los desarrolladores con el
objetivo final de establecer el intercambio de conocimientos y puntos de vista entre
ellos.

MSc. Ing. Wilfredo M. Trejo F. 4


ISI – INGENIERÍA DE SOFTWARE II 2019-II

Tipos de arquitecturas:
Para utilizar la arquitectura de software se sigue un conjunto de patrones
arquitectónicos, entre los cuales podemos encontrar:
✓ Cliente-Servidor
✓ Blackboard.
✓ Modelo entre capas.
✓ Intérprete.
✓ Orientado a servicios.

Toda arquitectura de software debe describir diversos aspectos del software.


Generalmente, cada uno de estos aspectos se describe de una manera más comprensible
si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos
constituye una descripción parcial de una misma arquitectura y es deseable que exista
cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes
entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para
describir una arquitectura. No obstante, existen al menos tres vistas absolutamente
fundamentales en cualquier arquitectura:
✓ La visión estática: describe qué componentes tiene la arquitectura.
✓ La visión funcional: describe qué hace cada componente.
✓ La visión dinámica: describe cómo se comportan los componentes a lo largo
del tiempo y como interactúan entre sí.

Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e


inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:
✓ Descomposición Modular. Donde el software se estructura en grupos
funcionales muy acoplados.
✓ Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes
independientes, pero sin reparto claro de funciones.
✓ Arquitectura de tres niveles. Especialización de la arquitectura cliente-
servidor donde la carga se divide en tres partes (o capas) con un reparto claro
de funciones: una capa para la presentación (interfaz de usuario), otra para el
cálculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia). Una capa solamente tiene relación con la
siguiente.
Otras arquitecturas menos conocidas son:
✓ Modelo Vista Controlador.
✓ Entre pares.
✓ Orientada a servicios (SOA del inglés Service-Oriented Architecture).

MSc. Ing. Wilfredo M. Trejo F. 5


ISI – INGENIERÍA DE SOFTWARE II 2019-II

✓ Arquitectura de microservicios (MSA del inglés MicroServices Architecture).


Algunos consideran que es una especialización de una forma de implementar
SOA.

IV. DISEÑO DE INTERFACES


Diseñar la interfaz de usuario es un proceso que empieza con la creación de diferentes
modelos de función del sistema. De acuerdo a la estructuración del software se pueden
crear los siguientes modelos:

✓ Un modelo del diseño del sistema, que incorpora representaciones de datos,


arquitectónicos, de interfaces y procedimentales del software.
✓ Un modelo de usuario que muestra el perfil de los usuarios finales del sistema.
En la etapa de análisis del proyecto se ubica a la población objetivo que en su
totalidad está constituida por profesionales de diferentes áreas, por ello debe estar
dirigido a su fácil entendimiento.

Normalmente el proceso del diseño de la interfaz del software es un proceso que se


lleva a cabo en colaboración con los usuarios finales del mismo. Este estudio hasta el
momento ha establecido que la población objetivo no tiene experiencia previa en
cuanto a ambientes virtuales se refiere. Por ende, es válido afirmar que la percepción
del sistema por parte de los usuarios finales es muy limitada. El proceso de diseño de
la interfaz se basa entonces en tomar en cuenta cuidadosamente las características de
la población objetivo, y en crear modelos preliminares que posteriormente son
ajustados y modificados en base a las recomendaciones y observaciones que hagan los
usuarios finales.

V. DISEÑO FRONT END


Como concepto frontend nos referimos a todo lo que tiene que ver con el desarrollo del
lado del cliente, la parte del proyecto que se ocupa de la capa de presentación. Sin
embargo, frontend lo podemos dividir a su vez en dos grandes partes, el diseño y la
programación. De por sí, son áreas bastante amplias y aunque están a veces
relacionadas, podemos encontrar profesionales frontend que se dedican únicamente al
diseño o a la programación.

En lo que respecta al diseño frontend existen a su vez una buena cantidad de tipos de
profesionales, desde maquetadores web a arquitectos de CSS o diseñadores de
interfaces de usuario o diseñadores de experiencia de usuario. También hay
diseñadores frontend especializados en el diseño de interfaces para aplicaciones
móviles y aun siendo una disciplina que no está relacionada con la web, la capa de
presentación de una aplicación móvil no deja de ser un tipo de frontal.

MSc. Ing. Wilfredo M. Trejo F. 6


ISI – INGENIERÍA DE SOFTWARE II 2019-II

Las tecnologías esenciales con las que trabaja un diseñador frontend son los estándares
abiertos para la web: HTML + CSS + Javascript, además de dominar una serie de
programas de diseño como pueden ser Photoshop, Illustrator, Sketch, etc. Dependiendo
de la actividad del profesional, podrá especializarse en unas u otras áreas. Lo ideal es
que todos al menos tengan unos conocimientos medianamente buenos de los lenguajes
básicos de la web HTML y CSS, pero a partir de ahí podrán especializarse en diversas
ramas.

Los más enfocados al diseño propiamente dicho deben tener conocimientos sobre
diseño de interfaces de usuario, así como diseño de experiencia de usuario. Se
interesarán principalmente en los programas para diseño gráfico y quizás menos en los
lenguajes. Los más enfocados a la maquetación web se interesarán en trasladar a
código el diseño, usando HTML y CSS, bajo unos estándares de codificación elevados,
que tengan en cuenta las características de la web y los navegadores.

Desarrollador Front-end:
Trabaja del lado Cliente, en el navegador, en el lado de lo que se ve. Principalmente se
ocupa de los componentes externos del sitio web o de la aplicación web. Como
consecuencia, deben dominar obligatoriamente:
✓ HTML: HyperText Markup Language, es el componente estructural clave de
todas las webs de internet. Sin él las páginas web no pueden existir.
✓ CSS: Cascading Style Sheets, es lo que le proporciona estilo a HTML.
✓ JavaScript: Usando solo HTML y CSS tus webs serían páginas estáticas, con JS
tus páginas web son interactivas.
En general se asocia a los desarrolladores front-end con los principios de diseño y de
estructura de páginas. Sin embargo, un desarrollador web va más allá que un diseñador.
Obviamente tiene que tener en cuenta la usabilidad y la legibilidad de la página o de la
aplicación web, pero como buen programador es consciente de que su trabajo se
ejecutará en el lado Cliente, en la mayoría de los casos, en el navegador. Y la
información no se almacena en el lado Cliente.
En la actualidad, además, va mucho más allá puesto que las capacidades de los
navegadores los han convertido en verdaderos "sistemas operativos" de la Web, con
APIs avanzadas que hace que las aplicaciones de lado cliente no tienen mucho que
envidiar a las apps nativas, nuevas versiones del lenguaje ECMAScript, multitud de
herramientas de desarrollo (npm, yarn, webpack...) y también meta-lenguajes (Sass,
TypeScript...) que hacen que sea una disciplina bastante compleja.

MSc. Ing. Wilfredo M. Trejo F. 7

También podría gustarte