Two paradigms characterize much of the research in the Information Systems discipline: behavioral science and design science The behavioral-science paradigm seeks to develop and verify theories that explain or predict human or organizational behavior The design-science paradigm seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts Both paradigms are foundational to the IS discipline, positioned as it is at the confluence of people, organizations, and technology Our objective is to describe the performance of design-science research in Information Systems via a concise conceptual framework and clear guidelines for understanding, executing, and evaluating the research In the design-science paradigm, knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact Three recent exemplars in the research literature are used to demonstrate the application of these guidelines We conclude with an analysis of the challenges of performing high-quality design-science research in the context of the broader IS community

/pdf/design-science-in-information-systems-research-1f7l0yvs8e.pdf

Design science in information systems research

How has Japan become a major economic power, a world leader in the automotive and electronics industries? What is the secret of their success? The consensus has been that, though the Japanese are not particularly innovative, they are exceptionally skilful at imitation, at improving products that already exist. But now two leading Japanese business experts, Ikujiro Nonaka and Hiro Takeuchi, turn this conventional wisdom on its head: Japanese firms are successful, they contend, precisely because they are innovative, because they create new knowledge and use it to produce successful products and technologies. Examining case studies drawn from such firms as Honda, Canon, Matsushita, NEC, 3M, GE, and the U.S. Marines, this book reveals how Japanese companies translate tacit to explicit knowledge and use it to produce new processes, products, and services.

The knowledge-creating company : how Japanese companies create the dynamics of innovation

This paper explores the development of information systems and computer ethics along separate trajectories over the 20 years since the first Manchester Conference, and ponders how things might have been and could be different. Along each trajectory, the challenge of aligning theory and practice has stimulated much research. We evaluate some of this research with respect to this alignment, discuss ethical theories and behavior, and explore the role of education in the development of practitioners who can and do behave ethically. We recommend the inclusion of the ethics of care, and more research into the teaching and learning of ethics as part of the personal journey of students, teachers, and practitioners.

Whatever happened to information systems ethics? Caught between the devil and the deep blue sea

http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/lecturas/03_1_Agile_Manifesto.pdf

Manifesto for agile software development

Individualism and collectivism

(NOTE: Each chapter concludes with a summary.) Preface. I. THE PROCESS. 1. Software Development Best Practices. The Value of Software. Symptoms and Root Causes of Software Development Problems. Software Best Practices. Develop Software Iteratively. Manage Requirements. Use Component-Based Architectures. Visually Model Software. Continuously Verify Software Quality. Control Changes to Software. The Rational Unified Process. 2. The Rational Unified Process. What Is the Rational Unified Process? The Rational Unified Process as a Product. Software Best Practices in the Rational Unified Process. Other Key Features of the Rational Unified Process. A Brief History of the Rational Unified Process. 3. Static Structure: Process Description. A Model of the Rational Unified Process. Roles. Activities. Artifacts. Disciplines. Workflows. Additional Process Elements. A Process Framework. 4. Dynamic Structure: Iterative Development. The Sequential Process. Overcoming Difficulties: Iterate! Gaining Control: Phases and Milestones. A Shifting Focus across the Cycle. Phases Revisited. Benefits of an Iterative Approach. 5. An Architecture-Centric Process. The Importance of Models. Architecture. The Importance of Architecture. A Definition of Architecture. Architecture Representation. An Architecture-Centric Process. The Purpose of Architecture. Component-Based Development. Other Architectural Concepts. 6. A Use-Case-Driven Process. Definitions. Identifying Use Cases. Evolving Use Cases. Organizing Use Cases. Use Cases in the Process. II. PROCESS DISCIPLINES. 7. The Project Management Discipline. Purpose. Planning an Iterative Project. The Concept of Risk. The Concept of Measurement. Roles and Artifacts. Workflow. Building an Iteration Plan. 8. The Business Modeling Discipline. Purpose. Why Business Modeling? Using Software Engineering Techniques for Business Modeling. Business Modeling Scenarios. Roles and Artifacts. Workflow. From the Business Models to the Systems. Modeling the Software Development Business. Tool Support. 9. The Requirements Discipline. Purpose. What Is a Requirement? Types of Requirements. Capturing and Managing Requirements. Requirements Workflow. Roles in Requirements. Artifacts Used in Requirements. Tool Support. 10. The Analysis and Design Discipline. Purpose. Analysis versus Design. How Far Must Design Go? Roles and Artifacts. Designing a User-Centered Interface. The Design Model. The Analysis Model. The Role of Interfaces. Artifacts for Real-Time Systems. Component-Based Design. Workflow. Tool Support. 11. The Implementation Discipline. Purpose. Builds. Integration. Prototypes. Roles and Artifacts. Workflow. Tool Support. 12. The Test Discipline. Purpose. Testing in the Iterative Lifecycle. Dimensions of Testing. Roles and Artifacts. Workflow. Tool Support. 13. The Configuration and Change Management Discipline. Purpose. The CCM Cube. Roles and Artifacts. Workflow. Tool Support. 14. The Environment Discipline. Purpose. Process Engineering Process. Roles and Artifacts. Workflow. Tool Support. 15. The Deployment Discipline. Purpose. Roles and Artifacts. Workflow. 16. Typical Iteration Plans. Defining the Product Vision and the Business Case. Building an Architectural Prototype. Implementing the System. 17. Implementing the Rational Unified Process. Introduction. The Effect of Implementing a Process. Implementing the Rational Unified Process Step by Step. Implementing a Process Is a Project. Appendix A: Summary of Roles. Appendix B: Summary of Artifacts. Appendix C: Acronyms. Glossary. Bibliography. Index. 0321197704T11172003

The Rational Unified Process: An Introduction

The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the design's concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the software's static organization in its development environment. >

The 4+1 View Model of architecture

The metaphor of technical debt in software development was introduced two decades ago to explain to nontechnical stakeholders the need for what we call now "refactoring" As the term is being used to describe a wide range of phenomena, this paper proposes an organization of the technical debt landscape, and introduces the papers on technical debt contained in the issue

Technical Debt: From Metaphor to Theory and Practice

Preface. Goals of This Book. Who Should Read This Book? How to Use This Book. Organization and Special Features. For More Information. Second Edition. Acknowledgments. I. THE PROCESS. 1. Software Development Best Practices. The Value of Software. Symptoms and Root Causes of Software Development Problems. Software Best Practices. Develop Software Iteratively. Manage Requirements. Use Component-Based Architectures. Visually Model Software. Continuously Verify Software Quality. Control Changes to Software. The Rational Unified Process. Summary. 2. The Rational Unified Process. What Is the Rational Unified Process? The Rational Unified Process as a Product. Process Structure: Two Dimensions. Software Best Practices in the Rational Unified Process. Other Key Features of the Rational Unified Process. A Brief History of the Rational Unified Process. Summary. 3. Static Structure: Process Description. A Model of the Rational Unified Process. Workers. Activities. Artifacts. Workflows. Additional Process Elements. A Process Framework. Summary. 4. Dynamic Structure: Iterative Development. The Sequential Process. Overcoming Difficulties: Iterate! Gaining Control: Phases and Milestones. A Shifting Focus across the Cycle. Phases Revisited. Benefits of an Iterative Approach. Summary. 5. An Architecture-centric Process. The Importance of Models. Architecture. The Importance of Architecture. A Definition of Architecture. Architecture Representation. An Architecture-centric Process. The Purpose of Architecture. Component-Based Development. Other Architectural Concepts. Summary. 6. A Use-Case-Driven Process. Definitions. Identifying Use Cases. Evolving Use Cases. Organizing Use Cases. Use Cases in the Process. Summary. II. PROCESS WORKFLOWS. 7. The Project Management Workflow. Purpose. Planning an Iterative Project. The Concept of Risk. The Concept of Metrics. What Is a Metric? Workers and Artifacts. Workflow. Building an Iteration Plan. Summary. 8. The Business Modeling Workflow. Purpose. Why Business Modeling? Using Software Modeling Techniques for Business Modeling. Business Modeling Scenarios. Workers and Artifacts. Workflow. From the Business Models to the Systems. Modeling the Software Development Business. Tool Support. Summary. 9. The Requirements Workflow. Purpose. What Is a Requirement? Types of Requirements. Capturing and Managing Requirements. Designing a User-Centered Interface. Requirements Workflow. Workers in Requirements. Artifacts Used in Requirements. Tool Support. Summary. 10. The Analysis and Design Workflow. Purpose. Analysis versus Design. How Far Must Design Go? Workers and Artifacts. The Design Model. The Analysis Model. The Role of Interfaces. Artifacts for Real-Time Systems. Component-Based Design. Workflow. Tool Support. Summary. 11. The Implementation Workflow. Purpose. Builds. Integration. Prototypes. Workers and Artifacts. Workflow. Tool Support. Summary. 12. The Test Workflow. Purpose. Quality. Testing in the Iterative Lifecycle. Dimensions of Testing. The Test Model. Workers and Artifacts. Workflow. Tool Support. Summary. 13. The Configuration and Change Management Workflow. Purpose. The CCM Cube. Workers and Artifacts. Workflow. Tool Support. Summary. 14. The Environment Workflow. Purpose. Workers and Artifacts. Workflow. Summary. 15. The Deployment Workflow. Purpose. Workers and Artifacts. Workflow. Summary. 16. Typical Iteration Plans. Purpose. Defining the Product Vision and the Business Case. Building an Architectural Prototype. Implementing the System. Summary. 17. Configuring and Implementing the Rational Unified Process. Introduction. The Effect of Implementing a Process. Implementing the Rational Unified Process Step by Step. Configuring the Process. Implementing a Process Is a Project. Summary. Appendix A: Summary of Workers. Appendix B: Summary of Artifacts. Acronyms. Glossary. Bibliography. Index. 0201707101T04062001

The rational unified process

"Per Kroll and Philippe Kruchten are especially well suited to explain the RUP...because they have been the central forces inside Rational Software behind the creation of the RUP and its delivery to projects around the world."--From the Foreword by Grady BoochThis book is a comprehensive guide to modern software development practices, as embodied in the Rational Unified Process, or RUP. With the help of this book's practical advice and insight, software practitioners will learn how to tackle challenging development projects--small and large--using an iterative and risk-driven development approach with a proven track record.The Rational Unified Process Made Easy will teach you the key points involved in planning and managing iterative projects, the fundamentals of component design and software architecture, and the proper employment of use cases. All team members--from project managers to analysts, from developers to testers--will learn how to immediately apply the RUP to their work. You will learn that the RUP is a flexible, versatile process framework that can be tailored to suit the needs of development projects of all types and sizes.Key topics covered include: How to use the RUP to develop iteratively, adopt an architecture-centric approach, mitigate risk, and verify software quality Tasks associated with the four phases of the RUP: Inception, Elaboration, Construction, and Transition Roles and responsibilities of project managers, architects, analysts, developers, testers, and process engineers in a RUP project Incrementally adopting the RUP with minimal risk Common patterns for failure with the RUP--and how to avoid themUse this book to get quickly up to speed with the RUP, so you can easily employ the significant power of this process to increase the productivity of your team.0321166094B03062003

Philippe Kruchten

Papers

The Rational Unified Process: An Introduction

The 4+1 View Model of architecture

Technical Debt: From Metaphor to Theory and Practice

The rational unified process

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP