smiths
commented
3 years ago I'll record my feedback here as I do the review:
- I was looking for more information on the Scope, so I looked at the expanded outline. The expanded outline correctly says that we are focusing on SC, but I think we should first say that the scope is well-understood software that undergoes frequent change (maintenance). We then chose to further specialize to SC software because it fits the scope of Drasil, and incorporates our experience with other projects. Software that makes sense for development in Drasil should satisfy something like the following assumptions:
- software project is long-lived, say an expected lifetimes of 10 or more years
- the software artifacts should be of interest to multiple stakeholders, not just the original developer. The stakeholders will have different interests and backgrounds
- the domain of the software project should be well understood (In the white paper branch, under Papers/WP_GEnerateEverything, there is more information on what "well understood" means, but it probably doesn't make sense to go beyond the readers understanding of well understood for your purposes)
- In the Background section you mention "Software Artifacts". This is a good idea, but we want to watch that we don't give the impression that we currently generate all artifacts. For instance, we don't generate design documents or test cases.
- In the Process section, what are the patterns that will be summarized and extracted?
- In the Drasil Framework section, the "What Drasil is and what it isn't" section sounds like something that would be in the intro, but we can leave it here for the moment and re-evaluate as the writing proceeds
- I like that you are mentioning providing examples in the "The Drasil Framework" section
- Doesn't the subsection on "Reimplementing the case studies in Drasil" belong in the "Our Process" chapter?
- In the Results Chapter the "Originals versus Reimplementations" sounds like a difficult section to write, and it might not be that meaningful. You probably don't need to cover everything here. Having the full examples in appendices might be too much information. You could just point to the on-line versions. We should focus on the interesting differences. For the most part the originals and the reimplementations match. Where they don't it is usually because we found a better way of saying something. If there are examples where the process of codifying the knowledge led to a deeper understanding the actual physical problem, those would be great examples. Do you have examples like that?
- The Pervasive bugs example is a good one
- We haven't really measured usability in any meaningful way. Talking about it seems like a good idea, but I don't know if there is a whole section of content
- In the Results section, can you give examples of design for change? Things that we can quickly modify that have a significant impact? For instance, I like the example where we fixed the formula in GlassBR to remove the divide by 1000.
- Can we quantify how many lines of Drasil code are used to generate x number of lines of documentation and code? We could separate the Drasil infrastructure that stays the same between generative tasks, and just look at the "new" information that is added for a new problem. We could take this further and look at the amount of new information that is added between NoPCM and SWHS.
- The future work section seems like it could be expanded. :smile: The tasks that students are currently working on could be in your future work list. In particular, typing the expression language and introducing model types might be good additions.
JacquesCarette
szymczdm
Please review https://github.com/JacquesCarette/Drasil/blob/Writing/People/Dan/Thesis/Outline%20%2B%20Notes/Outline.rtf at your earliest convenience.