| User | Post |
|
2:13 am
February 28, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Post edited 7:49 am – February 28, 2010 by Luke Maurits
As proposed in this earlier thread, where the idea met with positive opinions, I think that now that preparation for SpaceUp is over, we should in the near future begin work on planning a CSTART Project Lifecycle to give us more overall organisation and structure. There is a Wiki page for this, and it features a little Notice Box saying that it is something we are currently working on and links to this thread. I thought this would be a good way to (i) make it clear to new comers that they can expect to see rapid development in this area, and (ii) encourage them to help out with the planning.
We should try to run this in the usual manner where discussion and planning happens here and then things migrate to the Wiki as we agree on them. I've been a little backward in putting some rough ideas on the Wiki first unilaterally – this is mainly to avoid newcomers from SpcaeUp seeing a nearly completely empty page and thinking we are horribly unorganised. We can absolutely rework what is currently there on the basis of discussions here.
Looking forward to seeing us get some good work done on this!
EDIT: This might be a good thing to organize another IRC meeting around.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
7:54 am
February 28, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
How should we go about implementing this? My thoughts are to just put a one column ordered list with color fill on the main page of the wiki.
Something that looks sort of like this. (I just made stuff up to fill space)
Simple and easy to read.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
8:11 am
February 28, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
|
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
8:11 am
February 28, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
I do like the idea of having all the projects listed somewhere in a simple colour-coded format. When you said on the main page of the Wiki, did you mean directly on the main page or on another page which was clearly linked to from the main page?
With regards to implementation, do you mean with things like how people will submit project proposals and how we will collect the votes to determine when red projects become yellow, etc? I think that, because of this need and many other, similar needs we are going to have (like voting on engineering decisons, etc.) we will eventually probably want to create our own web app (called "My CSTART" or something like that) which handles all this kind of thing. If we kept it simple and to-the-point this would not be such a big project. Someone who has experience in a PHP application framework like Symfony could put a solid beta together in well under a week.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
8:24 am
February 28, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
Post edited 8:25 am – February 28, 2010 by Rocket-To-The-Moon
I was thinking just putting the table on the front page of the wiki. It doesn't take up too much space and each item would be linked to the appropriate page (including the title which would link to the Project Lifecycle Planning page). We could truncate the main page list if we end up with a ton of red projects.
I honestly don't expect too much turnover so I don't really think that we need a robust system to add stuff.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
10:01 am
February 28, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
I agree that we shouldn't expect too much turn over, but when the time does come to promote a project to green we will need to have some sort of system in place to handle the voting on which one to promote. There will thus need to be a way to get projects into that system. It doesn't have to be anything remotely fancy. I'm not really sure why I said "well under a week" above when really one dedicated day would be entirely adequate.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
12:29 am
March 3, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Just an idea: perhaps rather than having a fixed number of allowable projects and promoting projects to active based on a vote when a spot becomes available, we could have people express a level of interest in a project. When a project is proposed, people can select a response from a set like this:
- I think this is a bad project idea.
- I think this is a good project idea.
- I think this is a good project idea and I would be interested in offering occasional, casual advice/ideas.
- I think this is a good project idea and I would be interested in seriously contributing to it.
- I think this is a good project idea and I would be interested in assuming a leadership position in it.
A project would become interested only once a certain threshold had been crossed for each level (e.g. we had a least 3 people interested in taking leadership positions, and at least 10 serious contributors). We might have to have the system discount people's responses depending upon current committments, e.g. somebody who already has a leadership position in one project shouldn't be able to express interest in becoming a leader for any other, in order to avoid every project getting green lighted by overly ambitious leaders. Thoughts?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
9:43 am
March 14, 2010
|
rpulkrabek
| | |
| Member | posts 349 | |
|
|
I would like to expand more on our current life cycle management. I would like to see that our designs are set to certain states. My thought is that the life cycle states would look something like this:
 
Every project/component will begin from the "Draft" state. When the designers are satisfied with their work, the will change the state to "Ready". From here, the community will continue their input on what should be changed. Then, when the community involved is satisfied, the state will change to "Checked". This will then be the state where voting can take place. When everyone is satisfied with the designs, the state can be changed to "Prototype" and the initial manufacturing steps can be taken into place. If there are flaws, the design will be changed until it has been approved for "Pilot". From here, we begin the testing phase as if it were a completed process while going back to fix any flaws that yet exist. When everything is working the way it should be, the state can be changed to "Released". When the project becomes worthless, the state will then change to "Reitired"/p>
There is one more thing I would like to propose. I believe we should determine some sort of naming convention, such as a running number. The actual name of the component/Project would be in the description. Or perhaps, we would prefer to have the name followed by a running number, such as OHKLA-001. In the states "Draft" and "Ready", the component can be modified and changed to a previous state (such as from "Ready" to "Draft". After the component has been changed to Checked, a new revision must be taken into place, such as OHKLA-002, if the design is in need of a change. These names/numbers will then appear in the bill of materials for an assembly, so that we know exactly what is involved. This maybe some sort of software that would need to be developed, so that we can reserve specific names/numbers for each design/document.
The states can also be used to set an access control. For example, anyone is allowed to view the products if they are involved in the state "Ready", but to modify, they will need to reserve a certain revision number.
Is this understandable?
|
|
|
5:49 pm
March 14, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
rpulkrabek said:
When everyone is satisfied with the designs, the state can be changed to "Prototype" and the initial manufacturing steps can be taken into place.
My main concern with this is that it suggests a fairly strict separation between design and manufacturing at the level of an entire project, when I think it might be nice to allow a slightly looser approach. For instance, I would be happy to see manufacturing begin on the OHKLA avionics module (if it was all designed, of course) if design work was still ongoing for the rocket engine – or vice versa. For a CLLARE example, I guess if we consider the separate CM and LL design, one could surely begin building a prototype LL before the CM design was finalised, as long as the few parts where the systems overlap were done. In fact, even with the LL itself, I would be happy to see a more piecewise approach. I wouldn't mind seeing a structural frame with an RCS system built so that we can test the RCS performance and reliability, even if, say, the landing engine or the avionics were still being worked on. Basically my concern is that if we wait until something is completely designed and that design is signed off on by the community before we start building anything, then we won't be building anything for a long time which will not be good for (i) maintaining public interest in the project or (ii) finding problems as we go. Remember the advice of Amaradillo Aerospace:
We approach rocket design much like software design – build many different incremental designs that we can test constantly and work out all the kinks as we go. Build, test, fix, then test again.
Following a typical Big Aerospace design approach would be like programming a software design for months or years without ever being able to compile and test your code. And then getting only one chance to let 'er rip, crossing your fingers and hoping all your mountains of paper studies will pay off and nothing will go wrong the first time out. NASA has shown that such an approach can work, but at such great cost and time that a great many of its projects never move beyond the paper study stage. We'd rather actually fly everything we design, and see in the real world what works and what doesn't, so we can build off that first-hand experience on future designs.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
11:40 pm
March 14, 2010
|
rpulkrabek
| | |
| Member | posts 349 | |
|
|
Luke Maurits said:
For instance, I would be happy to see manufacturing begin on the OHKLA avionics module (if it was all designed, of course) if design work was still ongoing for the rocket engine – or vice versa. For a CLLARE example, I guess if we consider the separate CM and LL design, one could surely begin building a prototype LL before the CM design was finalised, as long as the few parts where the systems overlap were done. In fact, even with the LL itself, I would be happy to see a more piecewise approach. I wouldn't mind seeing a structural frame with an RCS system built so that we can test the RCS performance and reliability, even if, say, the landing engine or the avionics were still being worked on. Basically my concern is that if we wait until something is completely designed and that design is signed off on by the community before we start building anything, then we won't be building anything for a long time which will not be good for (i) maintaining public interest in the project or (ii) finding problems as we go. Remember the advice of Amaradillo Aerospace:
With the life cycle I laid out, all of this can be accomplished. If the avionics module was set to "Proto" then some actual builds of the avionics module can be manufactured. If only one piece is set to "Proto", that one piece can be built. Each component would have their own life cycle, and each assembly would have their own life cycle. It wouldn't have to wait until the entire product's assembly has a state of "Proto", only that individual component.
I suggest this path for the use of CSTART funds. This way we know and understand where the money would be going. Money wouldn't be spent on any part until it has been decided it is ready to be manufactured. Of course, if one person wanted to build their own component with their own money, they wouldn't have to worry what state the component/assembly is in.
This is only a proposal of a life cycle. We can fine tune this if needed.
|
|
|
5:54 am
March 16, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Ah, sorry, I think I misunderstood. I thought that these status labels were for projects as a whole, not subcomponents of projects. I can't see anything drastically wrong with proposal, in light of this clarification.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
4:29 am
March 17, 2010
|
rpulkrabek
| | |
| Member | posts 349 | |
|
|
We can fine tune this life cycle also. For example, do we need the "Checked" state, or after the component is in ready, a vote determines if we move it to "Prototype"/p>
I think the most difficult aspect of this is how to track these states and who has access to control this. I am no programmer, but is there a way to have a text file that has the component name and number as well as the associated state, then some gui front end will display this information? If so, other information could also be associated, such as who was the designer and such.
|
|
|
7:00 pm
March 22, 2010
|
Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Post edited 7:13 pm – March 22, 2010 by Luke Maurits
I am not really sure if this belongs in "Project Lifecycle" or "Project Management", but some thoughts on how to proceed for "big projects", ala CLLARE.
As has been generally agreed to be good and as we are doing, a Project Proposals phase, in which broad-detail overall solutions to a project's requirements are proposed and given preliminary investigation. Once a Proposal is chosen, where to from there?
Perhaps a good next step (before the start of the Engineering Process, and in order to support this process), would be to do a complete systems model of the entire project: clearly define all of the subsystems that will be required: exactly what they will have to do and exactly how they will interact with other subystem. We could possibly use something like SysML for this. I am sure there is lots of free software to work with that format and produce nice big block diagrams of everything.
EDIT: From the Wikipedia article on SysML: "The advantages of SysML over UML for systems engineering become obvious
if you consider a concrete example, such as modeling an automotive
system. With SysML you can use Requirement diagrams to efficiently
capture functional, performance and interface requirements, whereas with
UML you are subject to the limitations of Use Case diagrams to define
high-level functional requirements. Likewise, with SysML you can use
Parametric diagrams to precisely define performance and quantitative
constraints such as maximum acceleration,
minimum curb weight, and total air conditioning capacity. UML provides no
straightforward mechanism to capture this sort of essential performance
and quantitative information.". Does this sound good to you, Denis?
Once this high level model is in place, it will be easier to precisely set out the beginning structure of the Design Decision Tree.
Do people think that this makes sense? If so, what is a good open and collaborative approach to coming up with the systems model?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
3:29 pm
May 17, 2010
|
antinode
| | |
| Member | posts 64 | |
|
|
Post edited 3:37 pm – May 17, 2010 by antinode
A project lifecycle model is very important in organizing a successful project and this still needs to be decided upon and implemented as soon as possible. Currently all work being done would be considered in the Design Phase, based on a very weak project specifications that should be have been decided in the proposed Outline Phase. People are completing work in various areas with no clear picture of what should actually be worked on and in what order. I came up with a lifecycle that is similar to what rpulkrabek proposed, but with slightly tweaked stages and easier to understand terminology.
Concept Phase
Anyone may may submit a project concept through a project proposal web form. The concept proposal must provide at least a brief overview of what the project would consist of, and its overall purpose would be. Concept artwork and references to existing similar projects are encouraged as well. Discussion is held as to if the concept is theoretically feasible. If these areas are all decided to be satisfactory, the project concept can then move to the Outline Phase.
Outline Phase
During this phase the project is broken down into multiple subsystems, and from there each subsystem is broken down into a collection of tasks organized in a task tree. The task tree would be implemented in project management software. No specific decisions are to be made. This is only to realize the scope of the project and what individual decision are to be made in the next phase. Once the task tree is decided complete, the project may then move to the Design Phase.
Design Phase
The task tree is to be realized in this phase. Tasks may be added, removed, and modified when deemed necessary. Computer modeling and simulation are to be used during this phase to determine design decisions where appropriate. Once all tasks are fully completed and the completed project design is proven theoretically viable, the project may move to the Build Phase.
Build Phase
The design specifications are physically implemented. Design changes may be necessary during this phase. Once all components are built or acquired and assembled to be mission ready, the project may move to the Test Phase.
Test Phase
All subsystems and procedures will be subjected to rigorous physical testing for any design errors or possible issues. Design and build changes may be necessary if issues are found. If the project is proven reliable and deemed mission ready, the project may move to the Mission Phase.
Mission Phase
The project purpose is realized.
Closing Phase
Mission findings are organized, reported, and archived. While all project data will be available to anyone, the organization is done with this particular project. The project is still open to being forked internally or by outside parties.
This proposed model is really just a traditional waterfall model with the addition of opening and closing phases, and terminology adjusted to be appropriate and easy to understand. While this model is widely used in all types of development it is not without criticism as can be seen in the Wikipedia article. The criticisms are pretty much what Luke has stated, being that there is necessary overlap between phases. While this is inevitable, it should be minimized as much as possible, as this could lead to unnecessary development costs. If building starts on a subsystem before design of other subsystems is finalized, it is very likely design changes would need to be implemented that would affect interoperability, requiring changes to be made to the subsystem being built. You don't want to start building components with square holes before research is done that shows that round pegs are necessary. This results in wasted funds. While issues will certainly arise during the Build and Test phases that require design changes, I strongly believe that the design should be finalized before building begins to minimize these potential costs.
|
|
Login 
Register 
Search 
Home
Topic RSS 
