1. Why did you select the name Trirem?

Trirem is Latin for the Greek word, Trireme, meaning a large galley built to accommodate and equipped with three tiers of oarsmen inside the ship. The trirem ship was built by Phoenicians, a seafaring nation that dominated the sea routes of the Mediterranean with their ships and knowledge of the sea. The trirem was the battleship of its day, and powered by three tiers of oarsman was both fast and maneuverable; it dominated the sea from 2,200 BC until the sixth century AD. To this day, we do not know how the interior decks for the oarsman were arranged or how many men were required to man the oars on the second and third decks above the water. We can only surmise is that it took at least two men, and perhaps more, to operate the oars on the second and third decks. What we do know was that exceptional communication and coordination was required to get all oarsmen to operate as an effective team. The teamwork, communication, and efficiency essential to operating a trirem ship is what attracted me to the name “Trirem” for the company; those are the same qualities that we believe the company Trirem can bring to others through custom designed software and process reengineering.

2. What software development methodology do you use and why?

Trirem prefers to use the agile scrum methodology for software development. The scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

3. What is your process for gathering requirements?

We use a standard template for collecting requirements. We believe that collecting requirements is both art and science but we prefer to lean on the science component. We also believe that it is fundamentally impossible to expect any company to identify all business requirements at the beginning of a project; accordingly, the project must allow flexibility for the customer to add, even change requirements during the process. To deny the client that flexibility is unrealistic and it is the reason why the waterfall methodology has fallen out of favor with so many.

4. How do you gather information for the work break down study and who do you need to see?

We need to start initially with a company representative who understands all components of the process or processes you desire to modify. Then we need to discuss with your representative and understand what you want to modify, add to, or subtract from the process. Also, we need to understand what integration will be required of the customized software engineered process with other processes. Finally, we need to meet individually with everyone who performs any part or parts within the process that needs to be software engineered. Essentially, we need to understand the process flow, the inputs and outputs, the individual tasks that are performed during each step of the process. Furthermore, we need to know how, when, and where the tasks occur. Lastly, we need to understand what happens sequentially and in parallel during the process and what steps can be combined, modified, or eliminated. Collecting this information is essential to designing a new process that will achieve your objectives.

5. What is your test methodology and what testing tools do you use?

Testing is a critical component within any software engineering effort. The critical difference in testing methodology used in an agile scrum methodology is that we do not wait until all software development has been completed before performing testing beyond the unit level. The beauty of agile scrum is that it completes small increments of software development and testing as if it were a stand-alone component within the process. In this manner, we complete software development for a small but discrete part of the over process; perform comprehensive unit, system, and integration testing; and then deliver integrating software to you for beta and final testing. This method of building in short ‘sprints’ allows you to see product deliverables early and often; it also allows you to see your entire product unfold in complete increments as work progresses. This foregoes the major anxiety at the end of a project in which extensive beta and user testing is required because the agile scrum methodology is done progressively and frequently throughout the project. Furthermore, it facilitates changes initiated by the client throughout the entire process.

6. Under your expansible business model how long does it take you to bring on a new software engineer?

Given the nature of the software development industry, it is easy to obtain quality software engineers on short notice because many developers enjoy working from their home and setting their own work schedule. Our lead software developer has managed off-site software engineers in the past and is able, with great accuracy, to project what a developer should be able to achieve in a specific period of time and make work assignments based on achievable objectives. We also price work done by our developers based on known development competency. Ergo, the short answer to your question is that we are able to hire and make available extremely capable software development staff in less than 24 hours.

7. How do you differentiate between your software development methodology and management of the project?

We do not differentiate between the two; however, we modify the normal Project Management Book of Knowledge (PMBOK) methodology to accommodate the agile scrum development methodology. This accommodation is only in terms of the project time and test schedule. All other project components, such as: communication management, issue resolution and management, scope management, configuration management and version control, test management and control, implementation management and back out procedures, reports, certification, and post-certification reviews remain as suggested in the PMBOK.

8. Once you have collected the business requirements how do you convert them to technical specifications?

Translating business requirements to technical specifications is a collaborative process between the company, the Trirem project director, and Trirem’s lead software engineer. Once we receive your business requirements, the project director will meet with our lead software engineer. We will analyze the requirements and prepare as set of detailed follow on questions which we will submit to the company. As soon thereafter as possible we will sit down with the company representative who prepared the business requirements and work through each requirement using Trirem’s Business Requirements Collection Template. The template represents the bridge between a business requirement and the technical solution or specification proposed to meet that requirement. Once this effort is complete we will provide the company with our business proposal which will include our pricing estimate for the project which represents the total solution to meet all business requirements.

9. Have you ever worked with SAP software?

We are familiar with SAP technology but have not done an integration of customized software with a SAP software program. However, we have done extensive research on SAP technology and believe we can easily integrate our anticipated solution with SAP without issue. We are prepared to hire a software developer experienced in SAP to assist with the integration, if necessary.