Principle 6. Adapt the models you develop to the system at hand. It may be neces

Question

Principle 6. Adapt the models you develop to the system at hand. It may be necessary to adapt model notation or rules to the application; for example, a video game application might require a different modeling technique than real-time, embedded software that controls an automobile engine. Principle 7 .Try to build useful models, but forget about building perfect models. When building requirements and design models, a software engineer reaches a point of diminishing returns. That is, the effort required to make the model absolutely complete and internally consistent is not worth the benefits of these properties. Am I suggesting that modeling should be sloppy or low quality? The answer is "no." But modeling should be conducted with an eye to the next software engineering steps. Iterating endlessly to make a model "perfect" does not serve the need for agility. Principle 8. Don't become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary. Although everyone on a software team should try to use consistent notation during modeling, the most important characteristic of the model is to communicate Information that enables the next software engineering task. If a model does this successfully. Incorrect syntax can be forgiven. Principle 9. If your instincts tell you a model isn't right even though it seems okay on paper, you probably have reason to be concerned. If you are an experienced software engineer, trust your Instincts. Software work teaches many lessons some of them on a subconscious level. If something tells you that a design model is doomed to fall (even though you can't prove It explicitly), you have reason to spend additional time examining the model or developing a different one. Principle 10. Get feedback as soon as you can. Every model should be reviewed by members of the software team. The intent of these reviews is to provide feedback that can be used to correct modeling mistakes, change mis interpretations, and add features or functions that were Inadvertently omitted.

Explanation / Answer

principle 6 --> its like applying the hypothesis (the model) to test. we are testing whether our stated hypothesis is right or wrong. Keep checking how our program is actually responding to our model. principle 7 ---> model is just a demonstration of the overall software, it gives a basic idea of how the software has to be, with time our knowledge increases and hence we cannot state a perfect model, so forget about making it perfect, rather keep developing and leave a scope in the model to develop. principle 8 --> this is one of a trick of a lazy software engineer, understand the customer well, how he thinks and after all its our customer who is seeing the model, so even if the model's syntax are not perfect, if u can make your customer understand, that is enough. principle 9 --> believe your code more than your model. while modeling , try thinking as if you are coding it more than just modeling. This way you will realize whether the written model is workable or not. principle 10 --> generally after spending a lot of time on the software, its common to get saturated and not think of all the possible ways, reviewing it with your other team members, will help you determine whether there are any mistakes in your model.

Related Questions

Navigate

• Browse (All)
• Browse P
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.