The Cruiseterminal - The World's Floating Dock

Even by Dubai's standards the Cruiseterminal is an extravagant project. Rigged to a foundation in the Persian Gulf it can host three of the largest cruise ships. Its an integrated system comprising of its own photovoltaic electricity generation subsystem, an entertainment and retail subsystem, a 180 room lodging subsystem, docks for tens of smaller boats.

A system such as the cruiseterminal brings new challenges not only to system design and development, but also system operations, support and maintainability.

To check pictures of the Dubai floating Cruiseterminal among other structures, check De51gn at http://de51gn.com/design/the-floating-world-of-koen-olthuis/

One Way to Ruin a Great Product Idea - When Design and Implementation Miss

A friend of mine sent me some interesting pictures for projects that might have seemed successful on paper, when in implementation they failed. This is where a systems engineer comes in handy, in cases like these.

3 Ways To Guarantee a Failed Product

I was at the county jail a few weeks ago coaching a group of young men on strategies to transition back into society. I asked them two questions, the first list 3 goals you would like to accomplish during your lifetime, things you will be proud of in the hereafter. They jotted down some goals on 4*6 cards. The second question was list 3 things that if you do, you are 100% sure that there is no way you can achieve these goals, it will be impossible to achieve them. I gave them a few minutes and they all had a few points to share.

One example of a goal that was shared was to get back to education and enroll in college, get a degree and be a productive member of the society. The young man noted involvement with illegal substance to be a factor not allowing him to realize this goal.

Developing successful systems follow the same pattern. We need to understand user requirements, the utility of the system, why is the system needed, what value is the system offering, the gap it is filling. Once that goal is clear and understood, we need to make sure we protect these requirements from "outside noise", what is also known as scope creep. Scope creep is for sure a main reason why projects fail, it is when we add requirements, remove requirements, or just change requirements in an uncontrolled fashion, without going back to understanding the rationale and true value for doing so and relating it to the project's objective, cost and schedule.

Reason 1: Low Quality Requirements and Scope Creep - Uncontrolled Changes

A second young man in the group shared his goal was to be a successful businessman offering valuable services to the society. He noted down that unethical dealings would be a reason to ensure he never accomplishes his dream. I advised him that to overcome this hurdle he needs to continuously gauge his relationship with his Lord and measure his values and ethics. If he notices that his relationship is getting weaker, he needs to take corrective actions.

In the domain of systems development we call that validation and verification. Is the project still valid? i.e. is it still delivering what it was originally intended to deliver. And is the work correct? Can we verify that the work is what was expected earlier at the beginning of the project, through testing, and if it is not correct, can we take corrective actions to resolve defects. This validation and verification needs to be conducted throughout the whole life cycle of the product, and not just near the time we turn it over to the client, otherwise the deviations from the expected results could be huge, leading to costly modifications, schedule slippage and possibly a failed product.

Reason 2: Not Considering Validation and Verification Early in the life cycle of the product - Developing the wrong product, or developing the right product incorrectly

A third person shared that his goal was to be a teacher, nurturing young minds not only with knowledge but the application of the knowledge and its purpose. I reminded him to share with his future students trace back the purpose of the knowledge they learn from him, to the purpose for which we were created. Everything we do needs to serve the purpose for which our Lord created us.

Similarly, in the domain of product development, we can that requirements traceability. How do the original requirements defined by the client relate to design work, development work, testing and final product features. It is important that throughout the life cycle of a product we maintain a clear trace of how the work we are currently involved in relates back to what the customer needs.

Reason 3: Poor Requirements Traceability - Missing some Requirements in Implementation, adding Features not Needed, or both


Make sure if your customer asks for a mule, you deliver a mule as expected, and not a cow. Although a cow has plenty of benefits and utility, it might not serve the need satisfied by a mule.

ISO IEC 15288 / INCOSE SEBoK v3.0 Life Cycle Stages

Life-cycle definition is an important aspect of any system. By defining a life-cycle we can establish a framework for meeting stakeholder needs in an orderly fashion.

This order comes from the presence of stages in the life-cycle, and decision-making at the end of each stage to determine the readiness to move on. Stakeholders are concerned with the business case, funding and capability of a system at each stage.

INCOSE SEBoK ver 3.0 defines seven life-cycle phases. Each of these phases are listed below. Phases 2 - 7 are the same as the six phases defined in ISO 15288.

Pre-concept Phase:
Inputs: New ideas
Process: Creative systems engineering and requirements definition
Outputs: Identified enabling technologies

Concept Phase:
Inputs: Studies, experiments, models
Process: Requirements identification (if not done in pre-concept), indepth feasibility studies, prototypes, risk evaluation, early validation
Outputs: System requirements, feasible design solution

Development Phase:
Input: System requirements
Process: Development, integration, verification and validation
Outputs: Developed, verified and validated system

Production Phase:
Input: Tested system
Process: Modifications, re-verification, cost reduction
Output: Manufactured product

Utilization Stage:
Input: Performance reports, change requests, operational work orders
Process: Operations, change management
Output: Operational product, upgrades

Support Stage:
Inputs: Modifications, change requests
Process: Change control, maintenance, cost reduction, support
Output: Sustainable service and supported mission

Retirement Stage:
Inputs: change requests, competing systems
Process: System migration, removal, disposal
Output: Disposed system

Common Software System Development Methodologies

There are 4 common software system development methodologies. These methodologies comprise of:

(1) A process - to define activities or tasks to achieve the goal of the methodology
(2) A vocabulary - to describe the process and work products created during the process application.
(3) Rules and guidelines - to define the quality of the process and the work products

The four methodologies are shown in the table below along with their strengths and weaknesses.

Domain	RUP	Shlaer-Mellar	CRC	XP
Emphasis	- Incremental and iteration	- Execution for verification	Scenarios and simplicity	Simplicity, design through integration and refactoring
Strengths	- Comprehensive - Well Defined artifacts and roles - Incremental deliveries	- Simulation capability - Well defined testing rules - Well defined transition from one step in the process to another - Real-time system support	- Simplicity - Easy to use to transition from procedural to object oriented concepts - Focuses on object value, leading to optimized system	- Focuses and cares about the programming environment - Supports and requires close relationship between clients and developers - Accounts for changes in the development process
Weakness	- Large and difficult - Complicated rules - Customization is not straight-forward - Limited vendors supporting the process	- Considerable learning curve - Focuses too much on state modeling. - Limited vendors supporting the process	- Supports primarily classes - Requires a facilitator	- Relies on an ideal development environment - Depends extensively on client commitments - Requires high quality human interaction among development team - The system is in a constant state of maintenance

Have You Looked at the 2 F Words? Five Factors !

Developing a new product in no easy job. The uncertainity that looms around you seems endless. This uncertainity can be broken down into 5 areas as explained by Michael Porter, in his book "Competitive Advantage: Creating and Sustaining Superior Performance".

1. Potential entrants

2. Supplier Power

3. Buyer Power

4. Substitutes

5. Industry competitors

New Product Requirements

There are various sources for requirements gathering for a product or service. Obviously the most important source is the customer who will be using the product or service.

Another valuable source is the environment in which the product and customer will both be surrounded by. A list of the most relevant environments that a product manager or systems engineer should take a look at are:

1. Technological Environment
Presence of new inventions, innovation, methods, processes, materials to achieve new tasks or perform older one better, etc...

2. Economic Environment
The cyclical changes in local and global economies, inflation (prices rising/lower purchase power), recession (trade down/employment down), unemployment, depression (panic), recovery, prosperity (employment up/trade up), off-shoring, debt/savings levels, income distribution

3. Competitive Environment
The landscape of competing (monopoly, perfect, oligopoly, monopolistic), competitors status, etc...

4. Sociological Environment
Cultures, changes in industries, religion, subcultures (teens, seniors), crime rates, etc...

5. Political-Legal Environment
Legislation, regulations, PACs, wars, etc...

6. Demographic Environment
Age, gender, customs, location of residence, etc...

7. Natural Environment
Natural resources, raw materials, pollution, etc...

Astute system engineers should research all these environments. The level of research might differ from on environment area to another depending on the product/service being developed. In some cases other environments might be considered and some of those listed above ignored.