i* (pronounced "i star") or i* framework is a modeling language suitable for an early phase of system modeling in order to understand the problem domain. i* modeling language allows to model both as-is and to-be situations. The name i* refers to the notion of distributed intentionality which underlines the framework. It is an approach originally developed for modelling and reasoning about organizational environments and their information systems composed of heterogeneous actors with different, often competing, goals that depend on each other to undertake their tasks and achieve these goals. It covers both actor-oriented and Goal modeling. i* models answer the question WHO and WHY, not what.
In contrast, the UML Use case approach covers only functional goals, with actors directly involved in operations (typically with software). The KAOS approach covers goals of all types but is less concerned with the intentionality of actors.
The model describes dependencies among actors. There are four elements to describe them: goal, soft goal, task and resource. The central concept in i* is in fact that of the intentional actor. Organizational actors are viewed as having intentional properties such as goals, beliefs, abilities, and commitments (concept of distributed intentionality). Actors depend on each other for goals to be achieved, tasks to be performed and resources to be furnished. By depending on others, an actor may be able to achieve goals that are difficult or impossible to achieve on its own; on the other hand, an actor becomes vulnerable if the depended-on actors do not deliver. Actors are strategic in the sense that they are concerned about opportunities and vulnerabilities, and seek rearrangement of their environments that would better serve their interests by restructuring intentional relationships.
i* framework consists of two main modeling components:
An SD model describes a network of dependency relationships among various actors in an organisational context. The actor is usually identified within the context of the model. This model shows who an actor is and who depend on the work of an actor.
An SD model consists of a set of nodes and links connecting the actors. Nodes represent actors and each link represents a dependency between two actors. The depending actor is called Depender and the actor who is depended upon is called the Dependee.
An SR model allows modeling of the reasons associated with each actor and their dependencies, and provides information about how actors achieve their goals and soft goals. This model includes only elements considered as important enough to impact the results of a goal.
The SR model shows the dependencies of the actors by including the SD model. Relating to these dependencies, the SR model specifies goals, soft goals, tasks and resources. Compared with SD models, SR models provide a more detailed level of modeling by looking inside actors to model internal, intentional relationships. Intentional elements (goals, soft goals, tasks, resources) appear in the SR model not only as external dependencies, but also as internal elements linked by means-ends relationships and task-decompositions. The means-end links provide understanding about why an actor would engage in some tasks, pursue a goal, need a resource, or want a soft goal; the task-decomposition links provide a hierarchical description of intentional elements that make up a routine. Such a model is used to describe stakeholder interests and concerns, and how they might be addressed by different configurations of systems and environments.
i* provides the possibility to achieve information in an early phase of the software engineering process. In former days UML was used to make information visible, but as UML often focuses on organisational objects, which are not so important in the early phase, when the emphasis should be on helping stakeholders gain better understanding of the various possibilities for using information systems in their organizations.
i* models offer a number of levels of analysis, in terms of ability, workability, viability and believability.
i* provides an early understanding of the organizational relationships in a business domain. The Use Case development from organizational modeling using i* allows requirement engineers to establish a relationship between the functional requirements of the intended system and the organizational goals previously defined in the organization modeling.
i* can be used in requirements engineering to understand the problem domain. SD models and SR models can then be used to develop use cases. This is an ideal language to express Actors, Tasks, Resources, Goals and Softgoals.
i* is used for the early requirements and UML for late requirements. Thus one has to transform the i* model into a UML model. One can do this by using the following guidelines:
Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.
Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.
The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.
Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.
In software and systems engineering, the phrase use case is a polyseme with two senses:
In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.
A functional software architecture (FSA) is an architectural model that identifies enterprise functions, interactions and corresponding IT needs. These functions can be used as a reference by different domain experts to develop IT-systems as part of a co-operative information-driven enterprise. In this way, both software engineers and enterprise architects can create an information-driven, integrated organizational environment.
The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.
The Shlaer–Mellor method, also known as Object-Oriented Systems Analysis (OOSA) or Object-Oriented Analysis (OOA) is an object-oriented software development methodology introduced by Sally Shlaer and Stephen Mellor in 1988. The method makes the documented analysis so precise that it is possible to implement the analysis model directly by translation to the target architecture, rather than by elaborating model changes through a series of more platform-specific models. In the new millennium the Shlaer–Mellor method has migrated to the UML notation, becoming Executable UML.
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations, and the relationships among objects.
Extended Enterprise Modeling Language (EEML) in software engineering is a modelling language used for Enterprise modelling across a number of layers.
Goal-oriented Requirements Language (GRL), an i*-based modeling language used in systems development, is designed to support goal-oriented modeling and reasoning about requirements especially the non-functional requirements
Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.
ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.
Enterprise engineering is the body of knowledge, principles, and practices used to design all or part of an enterprise. An enterprise is a complex socio-technical system that comprises people, information, and technology that interact with each other and their environment in support of a common mission. One definition is: "an enterprise life-cycle oriented discipline for the identification, design, and implementation of enterprises and their continuous evolution", supported by enterprise modelling. The discipline examines each aspect of the enterprise, including business processes, information flows, material flows, and organizational structure. Enterprise engineering may focus on the design of the enterprise as a whole, or on the design and integration of certain business components.
A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.
TRAK is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.
The following outline is provided as an overview of and topical guide to project management: