Test, Execution and Recording

“It will work…” (Probably)

Based on Photo by Ksenia Chernaya from Pexels
Passed?

No product manager wants to be confirming their solution’s viability without the backup of evidence. It is imperative to test and assure your process or product. Tests should demonstrate conformance with, all the vital parameters that comprise your design; regulatory compliance; ongoing quality.

This whole quality cycle should include test, execution and recording functions.

Appropriate Testing

Cradle TER module - Test Case
Test Case

We should accept that these tests, and the effort used, should be commensurate with the importance of the design element. There’s every reason to test whether a product can place components with sub-millimetre accuracy if we’re designing a circuit board pick and place machine, but within a few mm is probably good enough for a machine placing variable size apples in a packing crate. When testing the same product used in different situations the complexity and accuracy of the test will change. Measuring the slump and hardness of concrete for a garden path, is probably judged by eye, three level compaction in a cone testing for a road, but you’d expect samples to be taken and lab tested it is being poured to form the main tower of a suspension bridge.

Scope

It is also important to test not only for the expected criteria, but the off-norms (off from normal) too. “The program shall accept user input of their weight in kilogrammes and their height in metres. Their BMI shall be displayed as a ratio of their (weight / height) to two decimal places” The previous requirements can be thoroughly tested for a full range of human weights and heights, but then fall over at the first hurdle when a user enters 0 for their height.

Executing

Cradle TER module - Test Run
Test Run

Once developed, the set of tests may need to be run multiple times on the same product as development tweaks are made, or once on each batch of product to ensure ongoing conformity. Services, procedures and physical products can all be tested. Whether that’s timing the office evacuation during a fire drill or the alcohol content of a batch of whiskey. It is also important to recognise that each execution set may need to be full or a partial set of the tests.   Every safety harness may be subject to visual inspection and, checks on fastener operation. Every tenth to a set of detailed measurements and every two hundredth to a full destruction test. The ability to execute a set of tests from our full suite is therefore important.

 

Recording

Cradle TER module - Test Result
Test Result

Finally the test execution will produce a set of results which should be recorded. Not only does the recording provide the traceability your QA (Quality assurance) plan should aim for, but it will allow you to investigate trends. How many failures were there last month? Were there more or fewer than the previous month. Is investigation required?

 

Cradle

Cradle’s TEST module  (Test, Execution & Recording (TER)) allows you to directly link Test Cases to your requirements, needs, or design elements. You can then define Test Plans and Test Executions to group and run these tests. And as you’d expect the tool will record the Test Results against each Test Step.

For more information download an evaluation copy of Cradle or book a webinar now.

TER video

How Risky?

Risk Management

Every project has risks associated with it. They range from the risks to the programme, supply chain, staff, technology; through financial backing and cash flow; to safety and performance of the product. But just how risky is it?

Recording, quantifying, mitigating and reviewing these risks helps reduce their likelihood and severity. The more complex the project the more risks you will need to manage and the greater the range and type that needs to be managed.

Risk Register example
Risk Register

Tools

Tools to manage risk don’t make the risks go away in themselves, a shiny RAG chart does not make a project safe. However, management is all about controlling these parameters. Visualisation and quantifying risks is a management aid to ensure effort is spent in the most appropriate place to give maximum benefit, and also to ensure the smaller issues don’t get completely lost at the periphery.

Parameters That Define Risk

Parameter Description
Likelihood
The probability of the risk occurring. This could be simply High, Medium and Low, or 9:10, 5:10, 1:10, or Daily, Monthly, Yearly.
Consequence
What impact does the risk occurring pose to the project. Again this could simply be a generic High, Medium and Low or a more ultimate Death, Hospitalisation, Injury or Catastrophic, Severe, Dangerous, Limited.
Magnitude
The importance or priority we assign to the risk given our assessment. These quantities are often associated with colours  e.g. High=Red, Medium=Orange, Low=Green. These would be the colour displayed on your RAG chart.
Dates
Some risks will only be present during certain parts of the project. Funding may only be an issue up to the point that the project is started. Manufacturing defects can be thought about but can’t start occurring until the production run starts, so don’t form part of the overall current profile until that point. Adding start and finish dates to your risks bounds them and allows you to show a chronological profile.

Finally every risk should be reviewed on a regular basis to make sure the parameters have not changed and the mitigations are still valid.

Value
Used to quantify the size of the risk should the risk’s event occur.
Owner
The person or organisation who is responsible for determining the mitigation of the risk and for monitoring how this mitigation is avoiding (negative risks) or promoting (positive risks) the risk’s associated event(s).
Mitigation
There is not much point identifying a risk if we make no effort to reduce it. Unless that is of course because it is below our threshold. The impact is low, and the probability is small and if it did occur the cost is small. In all other cases we should record what it is we intend to do to reduce the risk. We can then re evaluate the risk with the applied mitigation. We dig a hole in the street, likelihood is someone will fall down it, the impact is severe and the value would be expensive. This would generally be flagged as a High priority risk. The mitigation might be to assemble barriers before hole is dug. This does not reduce the severity of a fall or the cost to business, however the probability that someone will fall is drastically reduced, and thus the mitigation leads to a reassessment as a Medium priority risk.

Analysis

By selecting categories for each risk, grouping the likelihoods and consequences we can draw a matrix. A RAM (Risk Assessment Matrix) this provides a uniform method of quantifying the risks.

Likelihood Consequence
1 – TBD 2 – Low 3 – Medium 4 – High
1 – High High Medium High Critical
2 – Medium Medium Medium Medium High
3 – Low Low Low Medium Medium
4 – TBD TBD Low Medium High

For each risk we decide the likelihood it will occur (its probability), the consequence of it occurring (its impact) and then look up the magnitude given to the risk (its risk priority). When we then look at the project as a whole, we can see how many of these risks are classed as high or critical. These are areas that need resource and attention first. As noted above if the risks present themselves at different times during the project it is also possible to produce a chronological risk profile.

Visualisation and Profiling

How Risky – Counting

Risk graph example
Risk Count

Risks can simply be counted, and visualised as a graph over time. This gives a good indication of the number of each type of risk we are dealing with at any point throughout the project. However we should concentrate efforts on those most critical risks.

How Risky – Costs

Total risk profile example
Total Risk Count – Profile

Once we have an idea of the number of risks we have for each period of our project we can produce a risk profile.

Unfortunately this does not give us a picture of the overall cost to the project if these risks occur.

Maximum Risk Profile example
Maximum Risk – Profile

By assigning a value to each risk we can work out the overall ‘cost’ whether that be in time delays, money or some nominal value. For any point in time we have a maximum risk exposure.

How Risky – Weighting

Weighted Risk Profile example
Weighted Risk – Profile

However, we also must take a pragmatic view to the consequence of a risk and the effort that is reasonable to expend trying to mitigate it. If we have ten risks that have a fair chance of occurring, and will have an impact on our business, it is likely that we should spend effort mitigating these. Whilst we will want to mitigate against a  catastrophic risk, if its likelihood is “once in a blue moon” the amount of effort expended must be tempered. By assigning a weighting to our risks we can ensure the overall profile is adjusted to be more meaningful. There is no exact science to this but it is a tool to help focus the projects needs.

Mitigation and Review

It is important to record all the decisions and parameters used when assessing risks and designing mitigations. Whether this be reserving funds for an unexpected cost, or adding safety barriers round the hole. We’re sorry to say that adding a high-viz isn’t the correct mitigation for every risk!

Re-evaluate

Once each risk has been calculated and a mitigation has been assigned, its value should be recalculated in light of the mitigation. For example if we had identified a risk that members of the public may fall down holes we are digging to install fibre, our mitigation may include adding plastic barriers round the hole. The probability that a person will fall down a marked and barriers surrounded hole may reduce from a likelihood of  “Highly likely” to “Not very likely“. Whilst the overall count of risks will not have been reduced, the weighted profile will have lowered as although the cost of someone falling down the hole has reduced, the likelihood has been reduced.

Risks and the appropriate mitigations will change over time. This may be because a particular likelihood has increased, an element of the project has been delivered or delayed. So it is important to add review dates into your plan to ensure they are re-evaluated correctly. After all there is no point ordering all those plastic barriers to put round the hole if a project decision to sub contract hole digging was made a month earlier. Therefore you should always be asking “How risky is my project?”

Cradle

Cradle 7.6 introduces a new Risk Management module to help in planning for and managing project  risks. All the aspects above are held in Cradle attributes and each Risk item can be linked to any other Cradle item, e.g requirement, design note, diagram. This will help you manage the risks associated with each element of your project’s needs, and solutions. You can find more in the Risk section of the Cradle manual.

Related Articles

Cradle Risks video

Exchanging data/responses with your customers/suppliers

Data Exchange Mechanisms

The data to be exchanged, and the mechanism to be used to exchange it, will depend on the scenario between you and your customer. In this post we will outline the approach that can be used in two main scenarios when one of the parties isn’t using Cradle:

    • One to One – single need to single response
    • One to Many – single need may link to one or more responses

Each of these scenarios can be further varied by being a ‘one off’ or an iterative repeated exchange.

Scenario 1 -One to One

This scenario is where the customer has a list of needs and each need will only have one response, you then have the option of capturing the data only once or capturing the needs and responses multiple times.

Once-only Data Exchange (one to one)

The simplest approach where your customer/supplier has a list of needs, you can then respond to each need with values for the new attributes. One file is exchanged between you and the customer which they incorporate with their needs.

List of needs
List of needs from customer, each with an ID (n#)

Within Cradle you have a single item type for these needs, the item type would  be made up of the following attributes:

Need # Need ID (n#)
Need Text frame to store the need statement
Compliance Category to record the compliance of the response
Response Text frame to store a statement of how it is compliant
List of needs shown in WorkBench
List of needs shown in WorkBench

Responses would then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant.

Response to needs
Response to needs

 

Respones shown in WorkBench
Responses shown in WorkBench

There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).

Once all your responses are updated the next step is to create an export file to send to your customer.

Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:

    • Need #
    • Compliance
    • Response

To make this process easier you can set up export formats with the settings you want so that each time you want to run the process you don’t need to remember what the correct setting is. You can choose to load the export format which will instantly load the settings you have saved.

The customer then merges your response into their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.

Repeated Data Exchange (one to one)

Your customer/customer has a list of needs where there are multiple copies for each need, you would then respond with datestamps so that when the customer imports the file the correct needs are updated. One file is exchanged between you and the customer which they incorporate with their needs.

List of need with datestamp
List of needs from customer, each with an ID (n#) and a date

Within Cradle you have a single item type for these needs, the item type would be made up of the following attributes:

Need # Need ID (n#)
Need Text frame to store the need statement
Compliance Category to record the compliance of the response
Response Text frame to store a statement of how it is compliant
Need-Datestamp Category to record need date (ndate)
Response-Datestamp Category to record response date (rdate)
Needs with Datestamp in WorkBench
Needs with datestamp in WorkBench

Responses should then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant. Responses have a datestamp and will overwrite their predecessor when loaded.

Response to need with datestamp
Response to need with datestamp
Responses in WorkBench with datestamps
Responses in WorkBench with datestamps

Once all your responses are updated the next step is to create an export file to send to your customer. There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).

Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:

    • Need #
    • Need-Datestamp
    • Compliance
    • Response
    • Response-Datestamp

To make this process easier you can set up export formats. (See above regarding export formats)

The customer then merges your response into their needs by importing the file with overwrite set to merge. Responses have a datestamp and will overwrite their predecessor when loaded. The customer could also use import formats so each time you supply an update they have the correct import settings.

Scenario 2 -One to Many

This scenario is where the customer has a list of needs and each need may have many responses and/or a single response may be valid for multiple needs. The advantage of this scenario is that duplication of data is kept to a minimum, you also have the option of capturing the data only once or capturing the needs and responses multiple times.

Once-only Data Exchange (one to many)

Where your customer has a list of needs, you then respond with the new item (response) which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information.

List of needs
List of needs from customer, each with an ID (n#)
Needs in WorkBench
Needs shown in WorkBench

Within Cradle you have two item types one for needs and one for the responses.

The need item type would be made up of the following attributes:

Need # Need ID (n#)
Need Text frame to store the need statement
Compliance Category to record the compliance of the response

The response item type would be made up of the following attributes:

Response # Response ID (r#)
Response Text frame to store the response statement
Compliance Category to record the compliance of the response

Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.

Response to needs
New items as response to needs

 

Responses in WorkBench
Response 1 linked to multiple needs

Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.

Sends 1 file: Response #, Compliance, Response, list of related need #s
Or 2 files: Response #, Compliance, Response
Need #, Response #

To make this process easier you can set up export formats. (See above regarding export formats)

The customer then incorporates your responses with their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.

Repeated Data Exchange (one to many)

Where there are multiple copies for each need, you then respond with new items (responses) with a datestamp which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information as well as dealing with multiple copies of a need.

List of need with datestamp
List of needs from customer, each with an ID (n#) and a date

 

Needs with Datestamp in WorkBench
Needs with Datestamp shown in WorkBench

Within Cradle you have two item types, one for needs and one for the responses.

The need item type would be made up of the following attributes:

Need # Need ID (n#)
Need Text frame to store the need statement
Compliance Category to record the compliance of the response
Need-Datestamp Category to record need date (ndate)

The response item type would be made up of the following attributes:

Response # Response ID (r#)
Response Text frame to store the response statement
Compliance Category to record the compliance of the response
Response-Datestamp Category to record response date (rdate)

Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.

Response to needs with datestamps
Response to needs with datestamps

Responses are created for each need, each with an ID (r#). Responses
have a datestamp and overwrite their predecessor when loaded. All links to needs are replaced in each load.

Responses with datestamps and multiple versions in WorkBench
Response 1 linked to multiple needs with multiple copies of need 5/8

Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.

Sends 1 file: Response #, Need-Datestamp, Response-Datestamp, Compliance, Response, list of related need #s
Or 2 files: Response #, Need-Datestamp, Response-Datestamp, Compliance, Response
Need #, Response #

To make this process easier you can set up export formats with the settings you need so that each time you want to run the process you don’t need to remember what the correct settings are.

Customer loads responses and links each response to the associated needs. If the customer has multiple copies of each need, the need datestamps identify which needs to update. There are a number of options you can use to capture the data:

    • Load a Word table from Microsoft Word®
    • Using two CSV plain UTF-8 files one with responses and another with links
    • An industry-standard like ReqIF

“You’re a Cab”

Ambiguity

Airport Taxi
“Ready for Taxi”

“This is Delta Bravo Twoah Oner Niner, ready for Taxi”
“He’s just on his way now. – Going to Paris Avenue or Road is it ‘guv?”[1]

“Call me a Taxi”[2]
“You’re a Taxi”

“The project output
should be limited  
to 15 rows”        

“I hope we don’t argue anywhere near that much!”

Whilst the examples above are intended to amuse they do highlight the need to be clear about your intention. Whilst they are a play on the English language, translations to and from customers and suppliers can cause equal ambiguity, especially if auto translated.  Using a well known search engine the phrase “The ship shall have a 50m bow” translated to Greek “Το πλοίο θα έχει τόξο 50 μέτρων” and back again “The ship will have an arc of 50 meters” which could easily be interpreted as its turning ability rather than the size of the prow. We just hope they see sense and don’t order yards of ribbon.  The addition of engineering drawings would, in this case have made the design request clear. It could also be achieved by having the requirements in a hierarchical order. If this sentence appeared as a sub requirement of dimensions rather then manoeuvrability.

Interpretation

What is smooth?

Welding Photo by based on Danial Abdullah from Pexels
Smooth Welding

We have previously noted the difference between “should” and “shall”, that which is a desire and that which is a must. However, it is still important to remember the context and understanding of your stakeholders and suppliers. Say you need a framework to support a conveyor belt in a factory, you may contact a steelwork supplier. The required dimensions and weight bearing characteristics could be specified with a clear tolerance and safety margin. You may also specify that ‘all surfaces are  smooth’ . The latter requirement being driven by the need to keep your employees and products from getting cuts or snagged from rough welds or sharp edges.

Your supplier is used to making conveyor systems for use in food and medical supply factories. To them ‘smooth’ implies a high quality stainless steel, with surface pitting limited to parts of a millimetre to allow for hygienic sterilisation. This sort of accuracy and finishing does not come cheap. A bit over the top given your conveyor is only moving some boxes of nails and screws to a palletising area. Whilst this would have given an over manufactured product that fulfilled the brief, it would have been far worse if the customer supplier situation had been reversed.  It is important to remember there are many different view points depending where you sit in the chain. Understanding these differences and making your requirements match can reduce costs and prevent mistakes.

Manufacture

Manufacturing can introduce errors
Oops!

Even with clear unambiguous instructions, the implementation can still go awry. A requirement for a level concrete shed base that needed to be 13ft by 9ft, given to a local landscaper seemed pretty unambiguous. Dimensions and context were all clear. The site was cleared and the shuttering ordered. The 2″*4″(nominal) timber was cut and assembled. What could go wrong? Each piece of timber had been cut to a fairly precise tolerance. Oops! The width of the wood had not been taken into consideration. The internal width was therefore only 8’8″ and not 9ft…… Luckily this was caught by customer checking before the concrete was poured, otherwise it would have been very difficult to rectify. In many cases manufacture could be too far down the line to amend in the same way as the shuttering was extended. Prototypes and intermediate component validation can all help.

 

Take AIM

Plan and understand, to avoid requirement failure

  • Avoid Ambiguity use sensible breakdown and context,
  • Ensure all your suppliers and stakeholders make the same Interpretation
  • Check the Manufacture meets the design

Use the right tools to make your job easier and traceable

Don’t try and juggle the data in many different silos. You should ensure your requirements, design, risks, and measurements are held in one linked dataset. Select Cradle and AIM for quality and success.

 

[1] The term “guv” or guv’ner a contraction of governor a colloquial deference to a ‘boss’ or ‘chief’

[2] The terms “cab” and “taxi” are accepted as synonymous. They refer to a vehicle that can be hired for transportation. Customers are picked up from one location and driven to another, the vehicle is known as a taxicab. The terms “cab” or “taxi” are derived from the same root. Cab is more common in the USA and Taxi more frequently used in the UK.

National Swap Ideas Day 2020

Got an Idea?

Celebrating question mark
Got an Idea?

Swap Ideas Day 10th September 2020 is all about sharing your thoughts and ideas. This could be with colleagues, friends or working partners. However, it may even be that you have a great idea, that does not quite fit into your industry – so why not post it and share it with others?  It could be the spark of something beautiful.

If you have a great idea and want to share it you could tweet us @threesl or you could email us at social-customer@threesl.com. If we like it we may update this post and list it, so be sure to include your company contact details if you want them included.

What if I want to comment on a design, process or implementation detail?

Companies that are involved in design, production, through or end-life support should have a documented way to communicate ideas. Sometimes it is easy to miss the obvious, be blinkered by “that’s the way we have always done it” or get stuck without the vision of how to see ‘outside the box’.

White-boarding / Mind-mapping / Idea pooling / Video chat discussion

Whatever you want to call them these are intended to encourage imagination and creativity. To spark conversation, to record thoughts and to gather ideas. This is the most common point to share.

Review

A formal or informally conducted critique or consideration of a piece of work. This may be with colleagues, customers and/or other stakeholders. It’s aim is to promote comments and question, and thereby to ensure involved are happy with the development at this point in time.  The depth of the review will depend on the stage in the lifecycle and the criticality of the decisions and potential negative impacts if the work is not correct.  It can range from a cursory glance at an email to ensure all the facts brought up in a discussion have been covered, to a minute atomic step through Fagan Inspection.

Change Control

As a product moves through the cycle there may be a need to react to new requirements or changes in project constraints. This could be the results of another review, a technology demonstration, test measurements or supplier issues, which can also lead to a need to change. To prevent a loss of control, this must be a considered and documented process.  This could range from a simple agreement by email, or a formal request and review board approval.

Comments / Feedback

There always needs to be a way to react to changes, new ideas, issues raised by the user or customer. These may be positive “what if” or “could we also” or negative “it doesn’t” or “it really should”. However these arrive, as emails, comments on a social media platform, user feedback sessions, or questionnaires, our process should allow the feedback loop to feed back into the design cycle for consideration.

Tools Support

You’ll no doubt have heard us mention the need to make sure you have the ‘right tools for the job‘ a number of times. So it will be no surprise that  we have made sure Cradle supports these idea stages.

Idea Gathering.

Create an item type that records any meetings you have. You can assign frames to hold images, documents or any other binary data you like. Add some categories with values such as “Status” with values “Candidate” “Dismissed” “Future“. Add a Group or additional category to collect similar topics.

Review

User definable workflows allow reviews to be a simple recording mechanism with one approver, or to require  majority, unanimous etc. decisions. This gives full traceability of the decisions and when and who made them.

Change Control

Cradle supports formal Change Requests CHRs and Change Tasks CHTs.  Which, combined with the review mechanism and workflows, allow you to ensure alterations follow you process and procedures.

Comments

Discussions are an ideal way to add comments to any item in the Cradle database. They can be agreed / dismissed and follow a conversational thread  style.

Your Ideas:

If we receive any ideas they will be updated on our blog post here:

 

 

 

Terms and Conditions

Continue reading “National Swap Ideas Day 2020”

Cradle Supports Office – Not Office Apps in the Microsoft Store

Many of us use Microsoft Office to do our document-related work. There are now many versions of Office and many ways to get access to it. For example, you can buy, download and install it. Or, you can do this as part of a subscription service. You can also use simplified Office tools as pure web applications. Or you can use Office as a set of apps from the Microsoft Store. Cradle supports Office, but not the Office apps in the Microsoft Store.

Cradle’s Use of Office

Cradle uses Office tools in several ways:

  • Cradle’s Document Loader tool uses Word to split documents into items in the database
  • Cradle’s Document Publisher tool uses Word to assemble output documents from items in the database
  • Cradle has a plug-in for Excel. You can use this plug-in to load data from Excel into a Cradle database, either as new items or to merge into existing items
  • When you publish reports to HTML and CSV, you can view them in Excel
  • You can publish reports to RTF and view them in Word
  • Print your MBSE models’ diagrams directly to PowerPoint
  • You can link symbols in Visio diagrams to items in a Cradle database
  • Link a Work Breakdown Structure (WBS) in Cradle, bi-directionally, to the activities in a schedule in Project
  • Items in a Cradle database can contain rich text attributes that can be edited with Word
  • Items in a Cradle database can have attributes that can contain, or reference, any type of Office document

So your use of Cradle can be quite closely linked to Office. Hence it is a good idea to have a set of Office tools available when you use Cradle!

Supported Versions of Office

Cradle supports several versions of Office:

  • 2007 (SP3, 32-bit)
  • 2010 (SP2, 32-bit and 64-bit)
  • 2013 (SP1, 32-bit and 64-bit)
  • 2016 (32-bit and 64-bit)

You can install one of these versions of Office on your computer, either by buying it, or as part of an Office 365 subscription. Then, you install Cradle which will connect itself into Office to provide the facilities listed above.

Please do not install parts of different versions of Office. For example, do not install Project from Office 2016 with Office 2013 tools. If you do this, the Cradle installer will not install any of Cradle’s tools for Office.

Office 365

Office 365 is essentially a subscription service through which you can download the latest version of Office and install it onto one or more computers. So Office 365 produces the same result on your computer, you have an installation of Office. Hence Cradle supports Office 365.

UWP

The Universal Windows Platform (UWP) apps (previously called Windows Store apps and Metro-style apps) are apps that can be used across all compatible Microsoft Windows devices, including personal computers (PCs), tablets, smartphones, Xbox One, Microsoft HoloLens, and Internet of Things.

UWP apps are primarily purchased and downloaded via the Microsoft Store.

Microsoft Store

The Microsoft Store started as a means to distribute apps created for the Universal Windows Platform (UWP). Now, the Microsoft Store is the name for the consolidation of all of Microsoft’s previous distribution channels, including the Windows Marketplace, Windows Phone Store, Xbox Video, Xbox Music and the Xbox Games Store.

 

No supported Office version screenshot
No supported Office version

Please note that Cradle does NOT support Office products downloaded from the Microsoft Store.

External Articles

Here are a couple of articles on the differences between Microsoft’s Desktop apps and Microsoft Store apps:

What’s the Difference Between Microsoft Office’s Desktop, Web, and Mobile Apps?

Why ‘Office in the Windows Store’ isn’t really Microsoft Office

Office desktop apps now available for download from Windows Store in Windows 10 S

Is Nineteen a Magic Number?

Nineteen

A Number

19

It’s a number cardinally one more than 18, and one less than 20. It is a prime number, which some may class as mysterious . It can be prefixed with twenty, to start a long count down, or denote ‘this’ year (’20’-’19’).  Physics considers it one short of being magic in the sequence of nucleons in atomic shells (2, 8, 20, 50). In middle English nynetene derived from the concatenation of nigon + -tīene, but that does not make it magic. It was a political statement in a song by Paul Hardcastle, but it didn’t change the world.  It can be represented as XIX, 0x13, 10011 or |||| |||| |||| |||| but that does not make it magic. In the local shepherd counting dialect Cumbric, a Brittonic Celtic language,  it is Medder-a-Mimph (4 & 15),  which may sound magical, but casts no spell. It is a rather dark grey html color:rgb(19, 19, 19)▉ . Overall, there appears to be little significance to the number 19.

Too Few or Too Many?

However, in terms of Requirements, it could be a magic number. It does depend on your view point.

Dashboards showing ranges where 19 is good, insufficient or bad
19 A magic number?

Our example dashboard shows the same 19 Requirements could be considered Good, Insufficient or Over the top! If our example manufacturer is measuring the number of requirements for their  Information Display Unit, they could conceivably be happy with anything over 15 top level user requirements. Nineteen in this case would be considered in the happy zone and for this project a magic number. However, if these were the internal system requirements, experience tells them anything less than 200 is a bit short on detail 19 is certainly not magic. If these are specific regional variations to the product anything more than 10 may mean this is a different product, is suffering requirements creep and not just a variant, a little too much magic.

Conclusion

It is important to know what you are measuring and why. You can’t just say a number of requirements is good, bad or insufficient, until you know the context. Setting the parameter limits correctly, for the data you are trying to capture and analyse, is as important as capturing the data itself.

Sometimes these values have to be based on gut feeling. It’s better if they can be based on experience and foundationally more sound if they can be based on measured past experience.  So it’s important to remember, you could have a dashboard show you all green, and your project could still be in a rather brown mire.

We would like you to share your thoughts or experiences on choosing limits, or why nineteen is a magic number. We may include your comments in future updates, so please email social-customer@threesl.com

 

What is Engineering?

Engineering: (en-juhneer-ing)

The formal application of scientific and or mathematical principles to achieve a required goal.

This is quite a broad definition, there are many topics that are derived from the ‘pure sciences’ of  biology, chemistry, and physics and the mathematics behind them. Applying these sciences in different proportions gives us the terms we understand as engineering.  There are few ‘pure scientists’. Most professions require a mix with, say biology and chemistry to produce medicine or foodstuffs. Combine biology with physics to develop a space suit.  Physics and chemistry to produce batteries for your phone or car. Engineering is a mix of all these principles to solve problems and produce solutions.

Application of Science

As we, at 3SL, work (Software Engineers – application of logic and mathematical principles) there’s a construction site outside our windows. When you stop and think, there are a large number of principles being used in this civil engineering project. Definitely a lot of physics and mathematics, were used to calculate the safest ways to demolish the old building. A Police station, used to stand on this site. More science will have been used, by structural engineers, to calculate the forces and stresses in the new structure. A hotel and restaurant is to be built. Similarly the ‘Cast-In-Place’ 20m concrete piles that are being drilled into the ground will have chemical reactions occurring in the cement and ballast mix. These have been calculated and tested to produce the right strength pile to support the building.

You may not find much biology being applied on the site (save the organisms now living in the muddy puddles). However,  the chemicals used in the building from water pipes to paints will have had biological studies to ensure they are human safe, or how to use them safely.  Although,  when we have watched the seemingly graceful ballet of the excavators, diggers and trucks we can’t help feeling that the movements and joints were based on mother nature. The human and the control systems they operate, produce movements and operations which make it hard not to anthropomorphise the JCB!

Old Police station/ new Holiday Inn Express site Barrow-in-Furness
Civil Engineering Barrow-In-Furness

Discovery and Development

The principles used in engineering are or have been, observed empirically, calculated mathematically. They are then proven or developed by experimentation or modelling. The results are recorded and can be used in the next application. Therefore, that field of human endeavour moves forward. Whilst each engineering task will have a new goal, the principles that are applied will be based on the underlying sciences. The old building, that was removed, had different foundations from the new one. Development and testing move our engineering forward. We achieve more as knowledge and principles are built upon.

Application

Engineers need to understand the principles they are applying. Whilst these may be at very different levels, they still require planning and thought. No one would expect the building  to be produced by pressing one button on an ‘app’, but neither would you expect the civil engineers and architects to start experimenting with concrete mixes for every building. That’s not to say that there isn’t a group of engineers experimenting with different carbon fibre additives to give the concrete more strength at a reduced weight; their results being fed upwards to the building design engineers of the future.

Process

The formal application of these scientific principles, is how problem solving engineers meet the requirements. We know this as a design process. The whole being a ‘system’, this is systems engineering.  From the initial ideas and requirements management to the finished article, this engineering step is as crucial as the science principles upon which the solution relies. What ever engineering discipline you are in we hope you’ll agree, from concept to creation Cradle is the best tool you’ll see!

The Tail End

Whilst we agree that every job and every individual in our society plays an important role. There has been a bit of dilution of the ‘Engineering’ term in recent years. There’s a tendency for anything that is remotely technical to be labelled engineering. Anyone who understands which end of a screwdriver to hold gets called an engineer. Whilst I agree that there are chemical and physics principles afoot when I place the food in the pan for tea (dinner if you’re not from up North) and when I use the washing up liquid to clean the dishes, I don’t label myself a Domestic Engineer 😉

If you’d like to share your engineering thoughts for possible inclusion in a blog/Tweet/LinkedIn article, let us know your thoughts social-customer@threesl.com

Discussion Comments.

Continue reading “What is Engineering?”

Remote Workers and Cradle – Connecting with SSH Tunnels

Your company is using Cradle, but you’re a remote worker – how do you connect to the Cradle server?

If you have the Cradle client utilities installed locally without a local CDS then one method, if you have an externally accessible Linux/Unix system is SSH tunnels.

To use SSH tunnels you need to “lock down” the Cradle server to use specific ports, so they’re not randomly allocated from a wide pool.  You can do this in the $CRADLEHOME/admin/ports file.

Make a note of the internal IP address of the Cradle server – we’ll use CDS_IPADDR later in this post to reference this address. (In this test environment it is 192.168.11.168)

Cradle Configuration Changes

As an example of a small Cradle system with 6 users we can configure the ports file as such. (We’re setting ports for each possible user and an extra)

CDS_UDP_PORT_NUMBER = 23960
TOOL_UDP_PORT_NUMBER = 23961
PRJMAN_UDP_PORT_NUMBER = 23962

CDS_TCP_TOOL_PORT_NUMBER   = 16161
CDS_TCP_PRJMAN_PORT_NUMBER = 16162
UTILITIES_TCP_PORT_NUMBER   = 16163-16169
WBENCH_TCP_PORT_NUMBER      = 16170-16176
CWS_TCP_PORT_NUMBER         = 21211-21217
PRJMAN_TCP_PORT_NUMBER      = 16177

This ports file needs to be copied to all the clients using this CDS.

Putty Configuration Changes

Now we can look at configuring the SSH tunnels. To do this we’ll be using PuTTY – probably the most popular Windows SSH client.

First off, click on the Category Session and enter the hostname or IP of the externally accessible box in the Host Name field.
Now expand the category SSH and click on Tunnels.
For each of the ports configured in Cradle we need to add an entry.
So, for the first one:
Source port  23960
Destination CDS_IPADDR:23960
You can leave the radio buttons alone (set to Local & Auto)
Now click the Add button.

In the Forwarded Ports box you should now have an entry similar to:
L23960     192.168.11.168:23960

Repeat this for all the other ports and we end up with a Forwarded ports section which looks like (if you scroll up and down):

Cradle Putty Tunnel Settings

L23960 192.168.11.168:23960
L23961 192.168.11.168:23961
L23962 192.168.11.168:23962
L16161 192.168.11.168:16161
L16162 192.168.11.168:16162
L16163 192.168.11.168:16163
L16164 192.168.11.168:16164
L16165 192.168.11.168:16165
L16166 192.168.11.168:16166
L16167 192.168.11.168:16167
L16168 192.168.11.168:16168
L16169 192.168.11.168:16169
L16170 192.168.11.168:16170
L16171 192.168.11.168:16171
L16172 192.168.11.168:16172
L16173 192.168.11.168:16173
L16174 192.168.11.168:16174
L16175 192.168.11.168:16175
L16176 192.168.11.168:16176
L16177 192.168.11.168:16177

Click back on the category Session, then add a name to the Saved Sessions and click on Save – so we don’t have to do this again.

If you now click on Open and login to the Linux host.
You can now use your local Cradle client with it pointed to the CDS as being on your local IP.

While you have this SSH session active, you will be able to access the CDS over the SSH tunnels.

Related Articles

Remote Workers and Cradle – how do they communicate?

Count the Shalls

‘Shall’ Counting

“Count the shalls!” This was one of the strangest introductions to Requirements Management that I’ve heard. Firstly as a young engineer I didn’t know what a ‘shall‘ was, let alone why I should count it. For those of you reading this thinking “… no Idea what he’s on about..” let me explain. A crude method of working out the size of a project requirement was to count the number of paragraphs containing the word ‘shall‘. This gave the number of mandatory contractual statements that must be met for the project. Paragraphs containing ‘should‘ or ‘may‘ could be ignored as they were ‘nice to haves‘ rather than obligations.

counting the shalls as a method of determining contractual requirements
Shalls

Limitations

There is some logic to the approach, if the statements have been written atomically. However, as a provider one should never presume the customer has written the requirements to the right level for ‘shall counting‘.  For example these two customers’s requirement  sets are wildly different.

  1. The vehicle shall carry a load of 500Kg
  2. The vehicle shall pass legal requirements for use on UK roads.

and

  1. The pipe insulation shall be provided in 1m lengths
  2. Insulation shall be installable with standard DIY tools such as a craft knife and tie-wraps, and not require specialist equipment.
  3. The insulation shall achieve a thermal conductivity of  0.033W/mK or lower
  4. The insulation shall pass BS EN11925-2 BL
  5. No component material shall be classed as hazardous to health under COSHH regulations 2002
  6. The wholesale price point shall be 20p / m or lower

On a ‘shall‘ count the first project seems easiest just two requirements. But seriously!  would you accept a customer level requirement like this, and price up the work and expect a happy customer?
Have a Ford Transit, job done.
Then you find the customer wants to crane the load on.  Secondly you find they need a tailgate lift to unload it. Additionally you find the product needs weather protection during transit and so on.

The second project has SMART requirements
S pecific
M easurable
A ttainable
R ealisable
T raceable
Count the shalls here, and the measure may be a little more meaningful.

Shoulds and Mays

Can you afford to ignore ‘shoulds‘ and ‘mays‘ ? Contractually you could argue they don’t matter, but in forming a meaningful customer relationship, they are still important. “The insulation should be a mute colour” could contractually be met with vivid red foam, but you’re unlikely to get repeat business.

When the customer has an idea of the implementation (OK, requirements purists, don’t have a coronary) then they are guiding you as to the options they see as most appropriate.  “The vehicle shall have a mechanism to remove the load at a customer site” could be met with a separate fork lift truck being supplied. However “The vehicle may have a powered tailgate lift, or a body mounted mini crane” suggests the customer is seeing these as preferred solutions. In costing a bid these should certainly be considered. However, if your vehicles come with built in vehicle body to floor conveyors, this could still be a viable solution for the customer. After discussion your system requirement, linked to your customer requirement may become “The vehicle shall be fitted with a 800Kg NWL body/floor conveyor ” Of course this requirement would also have extra data within or linked to it minuting the discussion with the customer where they agreed this would meet their requirement.

Solutions

example of the types of language that should be evaluated automatically
Conformance Checker Settings

There are definitely merits  for someone or something to ‘count the shalls’. If you have 1678 requirements in your project and 1698 ‘shalls‘ you obviously have some non atomic requirements.  Running a Conformance Checker can validate the semantics, across your whole requirement set. What automated tools can’t do is look at the logic and complexity of the requirement. In these cases breaking your customer requirement into a number of domain specific system requirements ensures the level of the requirements against which you bid, design and build are truly SMART. Whilst unsurprisingly we advocate the use of a tool to manage your requirements, to link the User Requirements to the derived or system requirements, we don’t claim a tool will solve the problem of poor specification;  For that you need good, competent engineers, whose job is made easier by using the correct tools.