|
Tigris.org
Open Source Software Engineering Tools
|
|
|
horizon
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Project | Horizon |
|---|---|
| Author | Cristi Potlog |
| Version | Version: 0.1 (draft) |
The purpose of this document is to collect, analyze and define high-level needs and features of the project code named Horizon. It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist.
The details of how the application fulfils these needs will be detailed as use-cases and supplementary specifications in additional documents.
Project Horizon focuses on two major objectives. First, to provide an industry standard for producing software applications in a product-line manner. And secondly, to enable related processes with tools that guide developers on building such software, starting from the initial phases of product planning and envisioning, requirements gathering, analysis and design, as well as the actual development, test and release of the product.
Software Factories, or Software Product Lines are entire subsets of components that can be configured, assembled, and packaged to provide a fairly complete product. The resulting product should only require customization from a reasonably small team for the highly specialized aspects of the project.
Software must be carefully partitioned into distinct and reusable components and those components must readily fit together in a coherent manner. Configuration is the key to Software Factories, as projects must be able to pick and choose which components they want to utilize, and then generate an application off of that configuration.
We consider our first major release milestone to be the moment in which the process framework is mature enough to support complete automatic round-trip engineering between the model and the source code. This will enable Model-Driven Development even if the process already started with a rush-to-code approach, by extracting the model from the given source code and enabling high-level analysis and refactoring.
From the user perspective, we envision a system that will integrate requirements gathering, issue tracking and functional testing with the development process, by providing an unified IDE that is customized to each particular role defined by the process framework.
Every aspect of the process framework is thought to be extensible and configurable, not fixed by any means.
Future developments of the project will include support for definition of domain specific languages within the framework, that will seamlessly extend the possibilities of automating the software development process. This will allow much higher-level coding by providing additional an abstraction atop existing concepts within a specialized domain. Examples of a DSL include SQL and HTML. No matter what a specific project needs requires, if you have a database, you can use SQL and if you deal web pages, you can use HTML. Creating DSL's for other vertical concerns has been cost prohibitive because of the lack of tools. The scope first version of this project is just that, to provide tool support for domain specific languages and other extensions.
Another tool that will bolster development speed will be addition of autonomous agents (as in AI) that will guide developers through the process by offering instant tips and tricks on how to better complete a task by analyzing the context of the development state, just as today IDEs are able to suggest possible errors, or even workflow flaws, as the developer types in code.
For the first version of the product we intend to have a framework that will demonstrate the capability of this approach on a small scale project, as the classic Pet Shop application.
We target the first release on the Microsoft .NET Framework, maintaining though an level of abstraction that will enable portability to other software platforms, such as Java (J2EE) or LAMP (Linux&Apache&MySQL&PHP/Python/Pearl).
This subsection describes what the rest of the Vision document contains and explain how the document is organized.
1. Introduction
Provides an airplane-view of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references and overview of this Vision.
2. Positioning
Briefly describes the business opportunity being met by this project, summarizing at the highest level, the unique position the product intends to fill in the marketplace. It states the intent of the application and the importance of the project to all stakeholders.
3. Overview
This section provides a high level view of the project capabilities, interfaces to other applications and systems configurations.
It summarizes the major benefits and features the final product of this project will provide, putting the product in perspective to other related products and the user's environment.
It includes special issues like assumptions and dependencies, cost and pricing, licensing and installation.
4. Features
Lists and briefly describe the product features, as the document is.
Because the document is reviewed by a wide variety of involved people, the level of detail is general enough for everyone to understand. However, enough details are available to provide the team with the information they need to create a use-case model.
Also, this section documents any design constraints, external constraints, or other dependencies, and defines the priority of the different system features.
While all of the promises of Software Factories sound appealing, many companies have tried to provide the tools and components, only to fail under the load of inflexible tools or proprietary formats.
All of this is about to change. Big name companies like Microsoft and Sun are getting ready to release many of the components necessary for building and assembling a Software Factory within an organization.
While all of this conjecture sounds wonderful for the future, many developers will be asking themselves what they can do now to utilize Software Factory techniques in their organizations today. Well, the good news is that a lot of functionality already exists with Visual Studio.NET. Products like Enterprise Templates, Project Item Templates, and NAnt allow for the creation of standard artifacts that a team or organization can utilize today.
Software Factories are based on the convergence of key ideas in systematic reuse, model driven development, development by assembly and process frameworks. Many of these ideas are not new. What is new is their synthesis into an integrated approach that lets organizations with domain expertise implement the Software Factory pattern, building languages, patterns, frameworks and tools to automate development in narrow domains.
Our product is targeted at development teams that want to capitalize their market expertise through software modeling reuse by enabling software product-line development style of existing or new projects.
With the release of Visual Studio 2005, Microsoft has already unveiled several add-ins and plug-ins that enable the creation of not only Domain Specific Languages, but also the integration of those languages with the IDE itself. This will allow developers to manipulate and use the language from within the Visual Studio.NET IDE.
Not to be outdone, Sun Microsystems is working on its own implementation of Software Factory technology, simply named Project Ace.
We present these initiatives here to indicate that an large scale open source project is still missing from this picture. There is still room to grow and prosper, given that the market is at a infant age, and demand can be created and educated over time as current development approaches lack this degree of scalability and integration.
...
...
...
This system is provided as open-source software in both source and binary distribution packages. The packages will be available for download on a timely basis.
Redistribution and use in source and binary forms, with or without modification, are permitted under the terms of the BSD License.
The system will provide an integrated development environment (IDE) that will enable a common interface for all implemented functionality.
The system will offer a process template, as well as a way to extend and customize it.
The user can draw a graphic representation of the model that will be persisted.
The system will generate compilable source code from the model targeted at the Microsoft .NET Framework version 2.0.
The system will provide source control by using a third party SCM such as Subversion.
The user can use work items to break activity into steps. The system will track work items through the development process linking the work item with request that created it, regardless if this is an initial requirement, a reported bug or even a change request. By integrating with the source control repository the changes in the code will be attached to a specific work item.
The system will statically analysis generated and user modified code to detect potential problems.
The system will use autonomous agents to guide the user through the development process. The agents will help the user through ad-hoc tips for the task at hand, , all based on the selected process template.
The system will offer addition process templates, tailored for specific businesses or other development methodologies as CMMI or XP.
The system will target other software platforms such as Mono, Java or LAMP, as well as other development environments such as Visual Studio and Eclipse.
...
...
| Name | Description |
|---|---|
| DSL | Domain-Specific Language |
| MDA | Model-Driven Architecture |
| MDD | Model-Driven Development |
| IDE | Integrated Development Environment |
| J2EE | Java 2 Platform, Enterprise Edition |
| ... | ... |
The following features attributes are to be used to evaluate, track, prioritize and manage the product features proposed for implementation.
Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.
| Name | Description |
|---|---|
| Proposed | Used to describe features that are under discussion but have not yet been reviewed and accepted by the "official channel," such as a working group consisting of representatives from the project team, product management and user or customer community. |
| Approved | Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel. |
| Incorporated | Features incorporated into the product baseline at a specific point in time. |
Set by Marketing and the product manager in collaboration with the business expert and used in managing scope and determining development priority.
| Name | Description |
|---|---|
| Critical | Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip. |
| Important | Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature. |
| Useful | Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release. |
Set by the development team, used in managing scope and determining development priority.
Set by development team based on the probability the project will experience undesirable events.
Set by senior analyst and development team based on the probability the feature will change or the team's understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.
Records the intended product version in which the feature will first appear. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.
A person or a team will be responsible for further elicitation, writing the software requirements and implementation; helps everyone on the project team better understand responsibilities.
This field records an explanation or a reference to an explanation (used to track the source of the requested feature).