Administratively Controlled Information

Introduction and Background This is going to be hard – but also rewarding Survive beyond LEO Navigation Communication Things to consider - there is no magic here Back to Basics Planning Requirements – Isn’t a dirty word Systems Engineering Processes – It all depends Perils and Pitfalls Design, Develop, Integrate, Test, Repeat

Back to Basics Systems Engineering Use “good” engineering practices Tailor your approach to size, scope and importance of the task Light and agile processes Mission success first Cutting corners or eliminating doesn’t save, it costs Leverage recent collaboration advancements Focus on testing

Planning – A little bit goes a long way Don’t just rush in The grab bag approach of sticking a bunch of parts together is difficult for space Small teams have limited resources Maximize resource use by planning ahead Always ask “What problem are you trying to solve?” Goals and Objectives Architecture and ConOps Only as much as needed

Requirements – Isn’t a dirty word Requirements – has a stigma – lets call it something different “Functions”, “Task”, “Do-majiga” What it really means is “What does it have to do?” Start from Goals and Objectives Concept of Operations Work out your functions Break them down to elements Only break them down as far as you need to define your product/work elements Only as many as you need – otherwise delete it Rational – Why is it there? Does it need to be? How can your prove it Don’t create more to make the flow nice

Systems Engineering Processes – It all depends Only as much as you need and no more Processes are tools and only as useful as you use them they are there to assist not hinder Understand the benefits of processes and products Calculated Risk taking Configuration Management Do you need it? How much? Make it useable and agile Leverage electronic documentation but understand the limitations Reviews = Free technical advice

Design, Develop, Integrate, Test, Repeat “What problem are you trying to solve?” - Keep your eye on it Concentrate your early efforts on the hard stuff Doesn’t have to be linear – first time doesn’t always work Build up functionality as you go Set interim milestones/tests Build for access, testability and replacement DevSats, FlatSats, EDUs, Flight Spares If items are cheap buy more than you think you need Spares are priceless if they save you time Focus on testing to verify/validate the system Test to what level? (system vs. subsystem vs. component vs. part) Why are you doing the test? Focus on the core “Functions” Know the risks of delaying/eliminating your tests

Perils and Pitfalls – Learned the hard way Co-location / Communication Everyone on the same page Know where your going and how everyone fits in Clearly define roles, responsibilities and accountability Focused multi-disciplinary teams Make the right technical decisions Hardware pedigree versus heritage Identify long-leads early Don’t forget support equipment and test software Automotive or industrial grade over commercial

Take Home Points What problem are you trying to solve? Concept of Operations and Architecture What does it need to do? Back to Basics - Use good practices System Engineering processes and products are tools Only as much as you need Think ahead and plan Design, Develop, Integrate, Test, Repeat Concentrate your early efforts on the hard stuff Have fun!

Questions Contact Details: Work: