Solcept Workflow: The Steps of a Project

This first phase typically results in the following work- and information flows for you:

1. Confidentiality Agreement
   • together we sign an NDA to protect your information
2. Project Information/ Requirements Specifications ("Lastenheft")
   • in a first joint workshop we record your project information
   • additionally you provide your documents (PDF): requirements, existing products, technical information...
3. Draft Common Understanding of the Project
   • as it is very important for us to exactly understand your needs, we document all information about the project according to the workshop and your requirements documents in a common project understanding
   • you receive a PDF for review
4. Feedback
   • you give us feedback on this draft to ensure that we have understood your goals correctly
   • in the form that is easiest for you, either directly in the PDF, as an email or in a conference call
5. Final Version of the Common Understanding of the Project including Detailed Efforts and Initial Planning
   • as soon as all differences are resolved, we estimate the development efforts, roughly plan the project and thus create the final version of the project understanding
   • we present this estimation and the final common project understanding to you in a workshop
   • you receive the detailed estimate and the common understanding of the project as PDF
6. Offer and Order Process
   • this process takes place according to your preferences and processes

This first phase and the resulting documents are free of charge for you.

Graphically this looks like that:

The periodic project evaluations for each sprint, i.e. every four weeks, normally result in the following information flows:

1. Project Status Report
   • we create a project status report for you with, among other things, the following information:
     • technical target achievement and planning
     • efforts
     • risks and actions to mitigate risks
     • open points
   • you receive the report as PDF and it is stored on our Wiki
2. Project Status Meeting
   • your project management team discusses the report with our project manager in a conference call and sets the technical goals for the next sprints

Meetings are held only when needed, if possible, and generate the following information flows:

1. Invitation/ Draft Agenda
   • we create a draft agenda
   • you can customize the agenda on our Wiki
2. Meeting
   • your and our specialists decide on agenda items and action points
   • decisions and action points are documented directly in the Wiki
3. Protocol
   • we finalize the protocol with decisions and action points
   • you can review the minutes on our Wiki

If you discover errors in the results of the sprints or need changes implemented, the following processes and information flows typically result:

1. Customer Request
   • you document the technical behavior that you want to have changed
   • in a "Customer Request" ticket in our ticket system
2. Technical Clarification
   • together with you we clarify the technical behavior, when and how it will occur
   • the technical solution is documented in the "Customer Request" ticket
3. Triage/ Effort Estimation
   • bugs and small changes are implemented directly
   • larger changes are estimated first, so that you can decide on the effort and expense involved
   • the effort is documented in the "Customer Request" ticket
4. Implementation Decision
   • you decide on the implementation: 'Implement' or 'Do Not Implement'
   • in the "Customer Request" ticket
5. Implementation
   • we implement the desired solution

Graphically this looks like that:

When our risk management team discovers that important decisions need to be made about risks to the product, these interactions and information flows result:

1. Risk Assessment
   • together with your specialists we discuss the risk assessment
2. Substantial Decision
   • if the risk assessment or solutions differ greatly between our specialists and yours, we document the different assessments
   • as a "Substantial Decision" ticket in our ticket system
3. Mitigation Decision
   • you decide on the desired solution
   • in the "Substiantial Decision" ticket
4. Implementation
   • we implement the solution you have decided on

As a first step in a development project, we create the initial specification and system architecture with the key components, this leads to these interactions and information flows for you:

1. Requirements Specifications ("Lastenheft")/ Technical Information
   • your information from the project development phase and additional documents are collected
   • if needed, open questions are clarified in workshops
2. Draft System Specification ("Pflichtenheft")
   • in the system specifications we document all your requirements and the open issues
   • you receive a PDF ( also on our Wiki) for reviews and as a basis for possible workshops
3. Draft System Architecture
   • we create the basic structure of the product as soon as possible and select key components and key technologies
   • we check the impact of this architecture on the requirements specification
   • you get a PDF (also on our Wiki) for reviews and as a basis for possible workshops
4. Feedback/ Workshops
   • you provide feedback on both documents until a sufficiently stable state is reached for the start of implementation, this state mainly depends on the selected project type:
     • for classic with agile execution, more stability must be achieved, especially if the effort or dates are fixed
     • for fully agile, all existing information is included and no additional decisions on requirements need to be made in this phase
5. Release Decision
   • you release the system specification and maybe the system architecture as soon as the project risks have been sufficiently mitigated

The drafts of system specification ("Pflichtenheft") and system architecture are updated by us during the whole project as a basis for the implementation, the current version is provided to you on our Wiki as PDF.

Graphically this looks like that:

After an initial phase ("inception"), each four-week sprint for your software typically results in these interactions and information flows in which we incrementally and iteratively develop your optimal solution:

1. Software Implementation
   • we develop and verify a new (intermediate) release for your software based on the system architecture and the agreed backlog
   • we make this release available for download on our Wiki together with the test results
2. Integration, Test and Feedback
   • you test the software on the hardware and in your system
   • you report bugs and change requests to us as a "Customer Request" tickets in our ticket system
3. Backlog Decision
   • together with you we decide in a meeting (e.g. with MS Teams) on the features, changes and bug fixes that will be implemented in the next sprint

We carry out these cycles together until production release.

Electronics development follows slower cycles (typically 2..3 to production) with prototype production than software, you typically experience similar interactions and information flows:

1. Hardware Implementation
   • we develop and verify a new prototype for your electronics based on the system architecture
   • we provide the manufacturing data (Gerber, assembly data as spreadsheets) on our Wiki for you or the PCB manufacturer and assembler (EMS: Electronic Manufacturing Service)
2. Manufacturing
   • the PCBs are manufactured and assembled
3. Production Feedback
   • the PCB manufacturer and the EMS give feedback on the producibility of the electronics
     • therefore we try to have the prototypes produced by your series manufacturer
4. Verification
   • we test the electronics also together with the software
   • you have access to all manufacturing information, schematics and test results on our Wiki
   • you get the prototypes
5. Integration, Test and Feedback
   • you test the electronics with the software and in your system
   • you report errors and change requests to us as "Customer Request" tickets in our ticket system
6. Backlog Decision
   • together with you we decide in a meeting (e.g. with MS Teams) on the features, changes and bug fixes that will be implemented in the next prototype

We carry out these cycles together until production release.

When we perform the tests for certification and (pre-) series releases for electronics and software, the interactions and information flows look like this:

1. Release Candidate
   • we create and test the electronics and software
   • either we build it into your system or we deliver the boards for installation
   • you have access to all test data, schematics and manufacturing data on our Wiki
2. (Pre-) Compliance Tests
   • depending on the risk assessment, you, we or a test lab performs the compliance tests
   • we collect the test results on our Wiki
3. Validation/ Field Tests: Release
   • you perform the validation with the entire system
   • you release the (pre-) series by email
4. Development Data
   • you get all development data from us
   • as head revision of the Subversion repository, where we store all development artifacts

These tests and releases are performed according to your requirements, or those of your project/ program management, typically at least twice, first for the pre-compliance and then for the final compliance.

During the product maintenance phase, after the series start, our ticket system remains accessible to you. This allows you to report problems, change requests or obsolescence as "Customer Requests".

Depending on the (Zero-Cost-of Ownership) warranty and service level we have agreed upon, we solve the problems for you.