Crucigrama UML

Mapa Conceptual: Educación Basada en Competencias

REFLEXION SOBRE EL CIBER-PLAGIO

El plagio académico parece haber existido siempre, pero con la “super carretera de la información”, el problema se ha incrementado gravemente, denominándose ciber-plagio.
Investigadores en el tema han hecho clasificaciones en las causas del ciber-plagio y todas apuntan a una falta de ética y mediocridad en el pensamiento del plagiario.
A los docentes nos corresponde la tarea de ser más cautelosos tanto con los trabajos que pedimos como las revisiones que realizamos a los mismos. Debemos dejar claramente definidas las normas bajo las cuales se entregarán los trabajos académicos.
Prevención y detección son dos intentos que si aplican, pueden llegar a reducir el problema: prevención con regulación punitiva se refiere al hecho de dejar claro el castigo que se ganará aquel estudiante al que se detecte plagio del trabajo.
Otra forma de prevenir, es la concientización sobre ética y honestidad que se debe mantener al realizar un trabajo académico.
La detección se puede llevar a cabo a través de la experiencia en el análisis y observación del docente, en diferentes aspectos tales como incongruencia de ideas, diferente tipo de letra, uso de palabras no ocupadas en el lenguaje común del estudiante, perfecta redacción, entre otras.
La detección también se puede llevar a cabo mediante el uso de herramientas tecnológicas, tales como los buscadores o software especializado como “copy catch”.
En la medida que el profesor dedique más tiempo y esfuerzo en la revisión de trabajos académicos, el resultado será más favorable al disminuir el problema del ciber-plagio.

Sesión 7. Actividad 4. Reporte de Sitios Educativos y Bibliotecas Virtuales

Después de recorrer los sitios educativos y bibliotecas virtuales sugeridos, concluyo lo siguiente:

Para la función Docente
Me interesó el conocer más acerca de la elaboración de Mapas Conceptuales, ya que en mi quehacer docente estará más clara la definición de conceptos y temas a desarrollar por medio de esta herramienta didáctica: http://cmap.ihmc.us/

Los siguientes sitios son algunos de los que acceso para la preparación de mis clases, que está enfocada a la Ingeniería de Software y desarrollo de Sistemas
• http://bdigital.eafit.edu.co/bdigita
• http://www.ingenierosoftware.com/calidad/cmm-cmmi.php
• http://www.oracle.com/applications/crm/siebel/index.html
• http://www.sap.com/mexico/company/index.epx

Para la función tutorial
Escogí la biblioteca virtual http://www.gutenberg.org/wiki/Main_Page, para motivar a los tutorados a seleccionar lectura sana y de gran riqueza de lenguaje (en algunos idiomas en los que son publicadas las obras).
Me pareció interesante el Portal argentino para promover los valores en la familia http://www.telar.org/portada/portada.php

Reflexión sobre experiencia en la búsqueda y cómo aplicarlo al quehacer educativo.

Teniendo claramente definido el objetivo del tema a buscar, es importante seleccionar el buscador con el que más familiarizados estemos, ya que nos permite navegar de manera más natural en los temas que se hayan encontrado. Utilizando metabuscadores, se puede hacer una selección más específica de los temas encontrados, además de que nos proporciona más rápidamente los documentos encontrados.
Es también muy importante conocer la fuente de información, porque debido a la facilidad con la que se puede subir información a la red, no todos los temas encontrados son confiables.
Considero para que un tema de investigación sea aceptable para dar calificación, debe contar con los siguientes elementos: Autor, Título del artículo, fecha de publicación, institución responsable (quién publica) y el lugar. Además, no debe ser una copia exacta (copy-paste) de lo que ya está escrito, sino una síntesis, resumen, cuadro sinóptico, mapa mental, mapa conceptual, entre otros. El idioma en el que esté escrito no debe ser una limitante para elaborar un trabajo de investigación.
También considero que deben de tomar nota de diferentes fuentes de información, no basarse solamente en una.
Es necesario motivar a los estudiantes para que nos entreguen trabajos de calidad, apoyados en las herramientas tecnológicas con las que contamos en la actualidad.

SESION 6.ACTIVIDAD 4. Evidencia de búsqueda. Definición de Arquitectura de Sotware

Published Software Architecture Definitions
• Modern Definitions
• Classic Definitions
Modern Definitions
1. From the book Software Architecture in Practice (2nd edition),
(Bass, Clements, Kazman; Addison-Wesley 2003:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
"Externally visible” properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.
First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural.
Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. For example, all non-trivial projects are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to subteams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system’s functionality is divided up and assigned to implementation teams.
Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system’s function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.
Third, the definition implies that every software system has an architecture because every system can be shown to be composed of elements and relations among them. In the most trivial case, a system is itself a single element -- an uninteresting and probably non-useful architecture, but an architecture nevertheless. Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction.
Fourth, the behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the architecture. This does not mean that the exact behavior and performance of every element must be documented in all circumstances; but to the extent that an element’s behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.
Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that the architecture will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. Assuming that we do not accept trial and error as the best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and hoping for the best—this raises the importance of architecture evaluation.
2. ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.
________________________________________
Classic Definitions
Rational Unified Process, 1999:
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999).
Perry and Wolf, 1992:
A set of architectural (or, if you will, design) elements that have a particular form. Perry and Wolf distinguish between processing elements, data elements, and connecting elements, and this taxonomy by and large persists through most other definitions and approaches.
Garlan and Shaw, 1993:
In what has come to be regarded as a seminal paper on software architecture , Mary Shaw and David Garlan suggest that software architecture is a level of design concerned with issues
...beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives."
Bass, et al., 1994:
Writing about a method to evaluate architectures with respect to the quality attributes they instill in a system , Bass and his colleagues write that ...the architectural design of a system can be described from (at least) three perspectives -- functional partitioning of its domain of interest, its structure, and the allocation of domain function to that structure.
Hayes-Roth, 1994:
Writing for the ARPA Domain-Specific Software Architecture (DSSA) program, Hayes-Roth says that software architecture is ...an abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections.
Garlan and Perry, 1995:
David Garlan and Dewayne Perry have adopted the following definition for their guest editorial to the April 1995 IEEE Transactions on Software Engineering devoted to software architecture: The structure of the components of a program/system, their nterrelationships, and principles and guidelines governing their design and evolution over time.
(The source of this definition was a weekly discussion group devoted to software architecture at the Software Engineering Institute.)
Boehm, et al., 1995
Barry Boehm and his students at the USC Center for Software Engineering write that: A software system architecture comprises
• A collection of software and system components, connections, and constraints.
• A collection of system stakeholders' need statements.
• A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.
Soni, Nord, and Hofmeister, 1995:
Soni, Nord, and Hofmeister of Siemens Corporate Research write that, based on structures found to be prevalent and influential in the development environment of industrial projects they studied, software architecture has at least four distinct incarnations:
Within each category, the structures describe the system from a different perspective:
• The conceptual architecture describes the system in terms of its major design elements and the relationships among them.
• The module interconnection architecture encompasses two orthogonal structures: functional decomposition and layers.
• The execution architecture describes the dynamic structure of a system.
• The code architecture describes how the source code, binaries, and libraries are organized in the development environment.
Shaw, 1995: At the First International Workshop on Architectures for Software Systems, Mary Shaw provided a much-needed clarification of the terminological chaos. Distilling the definitions and viewpoints (implicit or explicit) of the workshop's position papers, classifies the views of software architecture thus :
• Structural models all hold that software architecture is composed of components, connections among those components, plus (usually) some other aspect or aspects, including (grouping suggested by the authors):
• configuration, style
• constraints, semantics
• analyses, properties
• rationale, requirements, stakeholders' needs
Work in this area is exemplified by the development of architectural description languages (ADLs), which are formal languages that facilitate the description of an architecture's components and connections. The languages are usually graphical, and provide some form of "box and line" syntax for specifying components and hooking them together.
• Framework models are similar to the structural view, but their primary emphasis is on the (usually singular) coherent structure of the whole system, as opposed to concentrating on its composition. Framework models often target specific domains or problem classes. Work that exemplifies the framework view includes domain-specific software architectures, CORBA [55] or CORBA-based architecture models, and domain-specific component repositories (e.g., PRISM).
• Dynamic models emphasize the behavioral quality of systems. "Dynamic" may refer to changes in the overall system configuration, setting up or disabling pre-enabled communication or interaction pathways, or the dynamics involved in the progress of the computation, such as changing data values.
• Process models focus on construction of the architecture, and the steps or process involved in that construction. In this view, architecture is the result of following a process script. This view is exemplified by work in process programming for deriving architectures.

La tecnologia educativa del ayer vs la tecnologia que alcanza el éxito