1,721,546 research outputs found
Legal Issues regarding Software Use and Reuse within the European Union Legislation
This paper addresses the problem of legal issues in the use and reuse of a software artifact with reference to the European Union regulations. Up to now software have been protected by means of the author law, however they are very different from other artifacts subject to the author law. This problem is getting more urgent as reuse is becoming a widely used software development methodology. Guidelines for implementing an" almost safe" contract for using and reusing software artifact are presented here. Questions regarding common misconceptions of the rights of the purchasers are also described
Agile Methods, between Categorical imperatives and Lean Production
There are no one-size-fits-all solutions. The best
way I have been able to find is to use risk as a way
to determine where to go agile and where to go
document-driven. Thus, for example, if you are
developing a graphic user interface (GUI) for an
unprecedented decision support system and want
to document its requirements, the most frequent
answer you will get from users is, “I can’t tell you in
advance, but I’ll know it when I see it (IKIWISI).”
In such a case, it is a high risk to try to document
the GUI in advance, and with a GUI builder tool,
it is a low risk not to document it.
On the other hand, when you are outsourcing a
relatively stable piece of business logic to a contractor 10 time zones away, it is a high risk not to invest
in a significant amount of thorough documentation of the interfaces and protocols connecting the
outsourced software to the rest of your software.
And it will be important to encapsulate any agile
portions of the software within information-hiding
modules, following Parnas’s guidelines.
Thus, in many competitive 21st century applications, it will be important to avoid one-size-fits-all
solutions, and to use risk considerations to determine which parts of an application are best handled
by explicit documented knowledge, and which
parts are best handled by tacit interpersonal knowledge
L'Evoluzione dei Linguaggi di Programmazione: Analisi e Prospettive
E meglio usare FORTRAN o Basic? C o Pascal? C++ o ADA? Java o C#?
Generazioni di informatici hanno combattuto battaglie all’“ultimo sangue”
per difendere il “loro” linguaggio di programmazione, adducendo le piu svariate
motivazioni per giustificare la scelta. Nei 50 anni di storia dei linguaggi
di programmazione, la scelta tra “cambiare linguaggio” e “cambiare il linguaggio”
sembra sia ricaduta sulla seconda opzione. In questo articolo, si
analizza lo sviluppo dei linguaggi con riferimento ai loro processi di sviluppo
Software Product Lines: a Succulent Minestrone with Many Flavours!
Software product lines aim at reducing the cost and
increasing the quality of software products by producing
multiple products synergistically. The underlying
assumption is that the benefits from the reuse of domain
specific software components will offset the extra cost for
the increased organizational complexity.
Product lines benefit from a collection of effects and
technologies, such as branding, minimal marginal costs,
network externalities, software reuse, and modularity in
the development process.
It is essential for a firm embracing a software product line
approach to determine the extent to which each of these
effects and technologies will be taken into account.
However, this is not an easy task because it requires a
deep understanding of the target market, its incumbents,
and the firm’s own position, and technical and financial
resources
Managing eXtreme Projects
Often people think at XP (eXtreme Programming) as a methodology where developers are free to do anything they want and take their life easy, in a nice and easygoing environment. It looks like as if requirement elicitation, analysis, design, and documentation had been abolished as useless. Moreover, project management had been buried as a damaging activity
The Cost of Standardizing Components for Software Reuse
Software reuse can be an important step towards increasing productivity and quality. A necessary condition for its success is standardization of reusable components at each level of the software lifecycle. Standardization can be looked at in two different ways: externally (the interface), and internally (functionality).
Both of these are fundamental, and imply extra costs in the development of components. The external perspective is the usual one—it considers the
appearance of the components and the ways they are related to the rest of the world. The internal perspective is strongly related to reuse: here a component is considered standard when its functionality is common among all systems belonging to a particular domain; such components are usually discovered following domain analysis. A qualitative analysis of these two approaches to standards and reuse led us to a simple model showing the extra costs of standardizing reusable software component
Un approccio lean alla generazione di modelli aziendali
Le organizzazioni lean si basano su un continuo miglioramento del
processo di produzione attraverso l’eliminazione del muda (spreco). Per
identificare le inefficienze e migliorare, il primo passo è costruire un
modello del proprio processo di produzione. Le tecniche tradizionali di
business process modelling sono basate su interviste fatte al personale,
per ciò il processo è lento ed è possibile individuare solo parte delle
relazioni effettivamente esistenti. Inoltre, è difficile capire se le modifiche
introdotte al processo producono effettivamente un miglioramento. Questo
articolo presenta un metodo per la generazione automatica di modelli
aziendali tramite la raccolta automatica di misure di process
- …
