1,721,546 research outputs found

    Legal Issues regarding Software Use and Reuse within the European Union Legislation

    No full text
    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

    No full text
    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

    No full text
    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!

    No full text
    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

    No full text
    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

    No full text
    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

    No full text
    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
    corecore