 Welcome to NASA and the Sailor Foundation Space System Engineering Course Unit 3, Project Life Cycle. The learning objectives for Unit 3 include, define what the NASA project life cycle is, identify the seven phases of the NASA project life cycle including key reviews, and explain the difference between formulation and implementation. Subunit 3.1, Project Life Cycle Overview. I'm going to talk a little bit today about the System Engineering Life Cycle, a big complex chart. You can see here on the first chart that it's got a lot of components to it. We're going to walk through it a little bit, and then we're going to also talk about some examples and try to put it in context. Some of the missions here at NASA that we're getting ready to fly or have flown in the past. So a project is divided into distinct life cycle phases with each phase having its own distinct purpose and its own distinct set of products. If you look at this first chart and you go through, there's two... This is thinking about a life cycle of a project from beginning to end. So you think about the left side of this page being the beginning. You know, you've got some ideas. Some scientists said, I'd love to look at supernovas and figure out what causes supernovas to go off. Now that's an idea, but now how do you build a satellite to do that? Maybe you don't even need a satellite. And so there's going to be ideas going around during the beginning about should it be a satellite? Should it be an Earth orbit? Maybe is it a big telescope that does it? Is it a radio gauge? Is it some other kind of photon counter? What is it? And so during the early parts of the beginning of this cycle, you're thinking about this idea and trying to mature it into a concept. The concept of how you're going to operate it and an architecture of equipment. Is it a spacecraft? Is it five spacecraft that have to orbit together to collect this data? What would this thing look like at a very high level? And so the beginning part of this chart is called the formulation part. And during the formulation, you're really thinking through ideas. You're developing these concepts of operations. How would this thing operate? You're developing these general architectures. You're doing a lot of analysis of different options that may be able to meet in many cases as a scientist requirement. So again, a scientist has an idea or in some cases a president has an idea. If you go back to Apollo, President Kennedy said, I want to send humans to the moon and bring them back by the end of the decade. That was a high level directive that now people could go off and say, well, how would you do that? What kind of vehicles would you need? How complex would that be? How expensive would it be? How long will it take? And so that's what this engineering cycle is going to try to do, is help you walk through from that original idea to a final set of systems that you can use and implement to accomplish that high level objective you started with. And so the first part of it is the formulation part. And in formulation, you're not building anything. You're starting the design process. But it's a high level where you maybe have four or five ways that you can think of to meet that objective. And so during this period, you're going to look at those four or five ways or however many there are. And you're going to try to neck down to one specific way of doing that seems to be the optimal. It seems to be maybe the most cost-effective. It fits the schedule that you've been given by some higher level managers. It fits in with the technical designs that would be able to be launched on the kind of rocket you're thinking about riding on. And so that first part of the formulation phase mostly involves computer simulations, paperwork, meetings and discussions, trade studies, analysis to try to get you to one single optimized design. And so by the time you hit in this chart, you see a big green triangle in the middle there. When you hit that part that says approved for implementation, that is a big deal at NASA. And a similar chart, a similar cycle is used by the Defense Department and a lot of commercial applications as well. But when you get to that green arrow, you're really transitioning from studies and analysis and more paper into a world where you're now going to start to procure and build and integrate and test and prepare for launch and then launch and operate the system. And so the right hand of the chart is called the implementation phase. And the implementation phase is when you're going to actually now focus on taking your point design, maturing it to the point where you have actual vehicles and you can actually go off and meet the objective. And so you'll see that going down the columns here, there are different phases to find, phase A or pre-phase A now, all the way through phase F, phase F being when this system is now done with its operation, it's met as objectives and you're going to retire it. And so it's a life cycle starting off with the concept and ending with the retirement of the system and the system being completed and meeting all of its operational objectives. And so you'll see here when you go through this chart that we'll talk a little bit about some of these different terms. There's a lot of acronyms. NASA loves acronyms. There's a lot of acronyms on here. But we'll talk a little bit about some of these. There are both technical reviews spread out throughout. We review requirements. We review designs to make sure that along the way technical peers are able to come in, evaluate how things are going and then give a go ahead technically to say, yes, this design or this system is maturing enough to be allowed to go to the next phase and become more defined and more complex. There are similar programmatic gates. You'll see these things called key decision points. Key decision points are at the end of every one of these phases, phase A, phase B. And the key decision point is a chance for the program managers to get together and discuss are we programmatically on track? Are we technically matured? Is our schedule still holding? Are we spending the right amount of money for this phase? Are there issues that we should be concerned about or risks? And so at each one of those programmatic gates, there's a decision again about whether to go forward and it's done by people that are not working on the project, but the program managers or the managers above them that have some oversight and responsibility for the project. So the idea is that you want to have these gates in place, both technical and programmatic, to make sure you're making the right amount of progress. You know, it's not a set in stone process that each phase takes a certain amount of time. It's really waiting until you think the system is mature enough so you go through the gate, show all of the specific products required at that review, like a requirements review. You show all of your requirements and you're given some go ahead or told to go back and do some further work before you can proceed. And so in the NASA System Engineering Handbook, there's lots of information about what level of maturity you should be at at each one of these reviews. So engineers know what products are required and what level of fidelity they need going into a review. Along the way, as you're developing a system through this life cycle, baselines are developed. Baselines and agreed to set of requirements, designs or documents that are established at each phase. And a baseline allows the team to all be working from a common set of whether it's requirements or design drawings. That baseline is something that you're going to control to make sure that the team has a common way of looking at the problem in a common set of tools to use. A baseline is a complete system description. It starts out at an early phase where you define the requirements for the system. As you go through the life cycle, you'll then move from defining requirements to doing design. As you go further on, you'll be developing other documents and those documents will all be controlled so that any changes to the documents are done through some formal process. And that's what it means to have baselined one of these products, is that it's now under the control system where if anybody wants to change it, they have to go through approval. It's a really great way to make sure that the whole team is using the same baseline, the same set of information to be working on. A baseline ensures the entire team's working with the same requirements, designs, constraints, assumptions. Again, we've talked about geographically diverse teams. We've talked about people working in their own discipline areas. You want to make sure that they all have a common set of tools and a common set of understanding of the basic designs and requirements and all of that that have to be used to develop the system. Now, click on the icon to read section 3.0, NASA Project Life Cycle from the NASA System Engineering Handbook.