By Topic

Software, IEEE

Issue 1 • Date Jan.-Feb. 2010

Filter Results

Displaying Results 1 - 24 of 24
  • Front Cover

    Page(s): c1
    Save to Project icon | Request Permissions | PDF file iconPDF (3179 KB)  
    Freely Available from IEEE
  • Table of Contents

    Page(s): c2 - 1
    Save to Project icon | Request Permissions | PDF file iconPDF (3238 KB)  
    Freely Available from IEEE
  • Déjà Vu: The Life of Software Engineering Ideas

    Page(s): 2 - 5
    Save to Project icon | Request Permissions | PDF file iconPDF (410 KB)  
    Freely Available from IEEE
  • IEEE Software Call for Applicants: Editor in Chief

    Page(s): 6
    Save to Project icon | Request Permissions | PDF file iconPDF (1382 KB)  
    Freely Available from IEEE
  • Kudos to Bob Glass and Rebecca Wirfs-Brock

    Page(s): 7 - 9
    Save to Project icon | Request Permissions | PDF file iconPDF (309 KB)  
    Freely Available from IEEE
  • Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases

    Page(s): 10 - 11
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (262 KB)  

    In the first part of this article, the author analyzed some common software architecture mistakes. In this article, the author discussed and explored the three mistakes that most architects know all too well. The author and his architect colleague Klaus Marquardt named these mistakes as if they were diseases: featuritis, flexibilitis, and performitis. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Unmasking Your Software's Ethical Risks

    Page(s): 12 - 13
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (323 KB)  

    It's difficult to fully address all our professional obligations as software engineers. Our training focuses on avoiding technical failures, but unfortunately our systems sometimes have unintended consequences. We need to develop products to avoid unintended negative impacts on society, people, and the environment. Professional responsibility requires that we identify the morally salient features of a situation. Some issues are relatively easy to spot; for example, we shouldn't lie to clients, we shouldn't bribe inspectors, and we should respect people's privacy. But some ethical and social risks are harder to recognize. Even developers with the best intentions have walked into ethical traps. When we study technical problems, we apply the project's constraints and priorities to find acceptable possible solutions and choose among them. Here are four suggestions for considering ethical constraints during that process, they are: look for human values in technical decision; identifying who will be affected; examining how stakeholders' right and obligation will be affectedl; and reviewing relevant professional standards to help identify issues. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software: What's In It and What's It In?

    Page(s): 14 - 16
    Save to Project icon | Request Permissions | PDF file iconPDF (1031 KB)  
    Freely Available from IEEE
  • Guest Editor's Introduction: Renewing the Software Project Management Life Cycle

    Page(s): 17 - 19
    Save to Project icon | Request Permissions | PDF file iconPDF (2768 KB)  
    Freely Available from IEEE
  • A Process for Managing Risks in Distributed Teams

    Page(s): 20 - 29
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (570 KB)  

    Today, many software projects are geographically distributed, so software managers must know how to manage distributed teams. For example, they need to know how to build teams across sites, how to break down and distribute tasks, how to share knowledge across time, space, and cultural differences, and how to coordinate work to produce coherent outcomes. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The rise and fall of the Chaos report figures

    Page(s): 30 - 36
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (745 KB)  

    This paper presents the chaos report figures that are often used to indicate problems in application software development project management, the reports contain major flaws. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A Lightweight Innovation Process for Software-Intensive Product Development

    Page(s): 37 - 45
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (637 KB)  

    An innovation process using face-to-face screening and idea refinement with heterogeneous audition teams can enhance the longterm perspective of product planning and development. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Trust Me, I'm an Analyst

    Page(s): 46 - 47
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (241 KB)  

    We often need to remind ourselves that, in the end, requirements projects are really all about people. Whatever new processes, techniques and software tools we come up with, it's still us folks who have to provide, analyze, and validate requirements. Success in requirements projects depends heavily on the domain knowledge and skills of the people involved, and the effective collaboration between them. After all, few requirements projects succeed without effective problem solving, collaboration, and negotiation.So let's remind ourselves requirements projects are about people. About people who do the right thing for their own requirements projects. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Choosing an Open Source License

    Page(s): 48 - 49
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (269 KB)  

    These days, many companies are struggling with ever-expanding software code bases. What to do with that set of homegrown libraries or that data processing application? Maintaining it could prove costly and divert engineers from working on new and innovative projects. There's one option that's attracting increased interest: release it as open source. Open source software is freely available software licensed for use and modification, including commercial activities. Anyone can copy, distribute or embed it as they see fit, without having to pay royalties or even negotiate a license agreement. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • How Pair Programming Really Works

    Page(s): 50 - 55
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (695 KB)  

    Pair programming has generated considerable controversy: some developers are enthusiastic about it, almost evangelical; others are dubious, even hostile. However, a large factor in this controversy is that programmers label a wide variety of practices under the "pair programming" umbrella. Thus, before our community can sensibly discuss how pair programming works, we first need to establish exactly what it is. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Four Trends Leading to Java Runtime Bloat

    Page(s): 56 - 63
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1165 KB)  

    Today, programmers work in an environment of rapid global development of large-scale applications that have become increasingly interconnected. These drivers are the backdrop for four important software engineering trends: the wide adoption of object-oriented principles, the pervasive use of abstractions, system and data integration, and the increasing need for software flexibility. Programmers no longer write monolithic applications; they assemble code from a sea of reuseable libraries and frameworks. Many programmers believe that improved productivity always outweighs any resulting loss in performance, but experience with large Java applications doesn't support this belief. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Object-Oriented Analysis: Is It Just Theory?

    Page(s): 64 - 71
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (458 KB)  

    Research and commercial surveys suggest that the object-oriented (OO) approach strongly supports the technical design and coding phases of software development but poorly supports the functional analysis phase. In other words, "the design is good, the analysis is poor." The source of this weakness is often attributed to the fact that "UML representations have not been effective in large-scale projects for context and communication." View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using a Line of Code Metric to Understand Software Rework

    Page(s): 72 - 77
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (401 KB)  

    A simple method measuring new effective lines of code showed that between 19 and 40 percent of code written on three projects wasn't in the final release. Generally, productivity is a function of input effort and output size. A strong understanding of software productivity, coupled with a good estimate of software size, is key to predicting project effort and, ultimately, producing reliable project duration estimates, schedules, and resource needs. Project managers and engineers often measure or predict the size of released software-the volume of software in the marketed product. However, the final release doesn't include reworked code-code that was changed or deleted during development. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Mining for Computing Jobs

    Page(s): 78 - 85
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (510 KB)  

    A Web content mining approach identified 20 job categories and the associated skills needs prevalent in the computing professions. Using a Web content data mining application, we extracted almost a quarter million unique IT job descriptions from various job search engines and distilled each to its required skill sets. We statistically examined these, revealing 20 clusters of similar skill sets that map to specific job definitions. The results allow software engineering professionals to tune their skills portfolio to match those in demand from real computing jobs across the US to attain more lucrative salaries and more mobility in a chaotic environment. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Self-Adaptation Using Multiagent Systems

    Page(s): 86 - 91
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (478 KB)  

    Each decade has its key software technology to advance artificial intelligence, and each technology is highlighted in a novel that sells much better than the underlying technology. Who hasn't read Michael Crichton's Prey and wondered how far multiagent systems might evolve and how they might affect humankind? Our technology column digs into this topic in this issue. Danny Weyns and Michael Georgeff provide a short introduction and show how multiagent systems help master the complexity of self-adaptive systems. They contrast multiagent systems with other current technologies and provide links and hints for practitioners who want to get started with this emerging field. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • 2009 Reviewers

    Page(s): 92 - 94
    Save to Project icon | Request Permissions | PDF file iconPDF (195 KB)  
    Freely Available from IEEE
  • Architecture as a Shared Hallucination

    Page(s): 96
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (216 KB)  

    This paper present the architecture of a software intensive system. An architecture is just a collective hunch, a shared hallucination, an assertion by a set of stakeholders about the nature of their observable world, be it a world that is or a world as they wish it to be. An architecture therefore serves as a means of anchoring an extended set of stakeholders to a common vision of that world, a vision around which they may rally, to which they are led, and for which they work collectively to make manifest. When I say that an architecture is a shared hallucination, I mean that an architecture-as-artifact is a naming of the mutually agreed-upon set of design decisions that shape a software-intensive system. While an architecture is just an abstraction of reality, an architecture-as-artifact is a declaration of that shared reality. In this way, that shared hallucination represents a common vision among a set of stakeholders as observed simultaneously through several different points of view and represented by a set of interlocking models. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • IEEE Software Call for Papers

    Page(s): c3
    Save to Project icon | Request Permissions | PDF file iconPDF (461 KB)  
    Freely Available from IEEE
  • Seapine Software Advertisement

    Page(s): c4
    Save to Project icon | Request Permissions | PDF file iconPDF (1183 KB)  
    Freely Available from IEEE

Aims & Scope

IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Forrest Shull
Fraunhofer Center for Experimental Software Engineering