Lean development methods prefer to steer the development through guidelines and principles rather than specification documents. In this way developers are empowered to maximise their creative input to the project. Iterative development process is built on Refactoring Application Interfaces, Data and Software Code. The ever-changing software base requires a Component architecture that is Built to change. Developer should always be ready to rewrite a component from scratch, component by component at a time. With major version number change, data cycle requires the whole system to be changed into a new environment overnight.
Developer Community Engagement Methodology
Developer community and management of the Open Source Project is built on the fact that open community enables software developer engagement on several levels: through peer support, co-creation and shared problem solving, innovation is quicker and recruitment easier than with some other development models.
If control on the Open API environment needs to be excerted, a API key, i.e. automatically assigned token can be configured, such as http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication Tokens should be available with automated assignation 24/7 for the API to still comply wit opendefinition.org principles. A web page where email is reqiested and token sent to that email for use in application-specific access should suffice to most scenarios. In this way control and blocking can be excerted API key -specifically. Helsinki City uses server firewall blacklisting, but otherwise opens the API:s fully, and problems haven't appeared as of yet.
Services are developed to address human needs. For example, the development of Journey Planner software services are designed to help users navigate a route from where they are (Point A) to where they want to go (Point B) using the most efficient and most convenient public transportation options available. Therefore, the creation of technical route-planning solutions should be informed and inspired by user stories. The non-technical descriptions of how users want and should be able to deploy services are called user stories. These user stories include multiple discrete steps and components, such as user needs, feature definitions, and solutions, which are called functionality modules. These non-technical descriptions of functionality modules are oftentimes consistent and repeated across different user stories, and therefore they are reusable. The functionality descriptions belowprovide non-technical descriptions of functionality modules that can be defined and reused across and different user stories in order to fulfill user needs in an efficient, interoperabledesign.
Architectural development principles are used as basis for making design choices when developing a new web service. Architectural principles have been adjusted to accommodate decentralized open source development, dispersed piloting and lean software development methodologies.