Ans : Provide 5 examples to support your position and limit your answer to 500 words or less.
This policy could reward inappropriate behavior such as
1. a programmer that is very careful to produce self-documenting code and thus may feel that he/she does not need to add extra documentation may be discouraged from continuing to produce self-documenting code.
2. mandating a specific number of documentation lines per 1000 LOC does not take into account that there are differences in the amount of documentation needed for different types of code - very complex algorithms may need more and standard business type apps may take less and rewarding them in the same way does not impress upon the programmers when documentation is appropriate and necessary.
3. mandating the amount and not the quality does not reward the programmer that produces clear, concise comments as opposed to the programmer that produces lots of rambling, confusing documentation.
4. to connect the code to the requirements, specification and design documents, the comments may in fact be very terse since they just reference these documents and thus once again this appropriate behaviour may be inadvertently discouraged.
5. this policy does not address the case where programmers are extending classes or modifying existing codes - there may not be a clear way to count either the real LOC or the appropriate number of comments since these are both influenced by previous work. If the current programmer is punished for the inappropriate behavior of others this will taint the programmer's view of extending or using other's code.
2. Compute the function point count for the system which is described in the following informal requirements statement. Clearly state all assumptions that you make.
Ans : The system processes various commands from an operator of a chemical plant. These commands include:
• calculate and display the average temperature of a specific reactor over a 24-hour period
• calculate and display the average pressure in a specific reactor over a 24-hour period
• calculate and display a summary of the average temperatures and pressures in a specific reactor over a given time period (where the time period is greater than 1 day)
The operator can also send the results to an electronic bulletin board.
3. Develop 4 different definitions for LOC that are most appropriate for the following purposes:
1. maintainability
2. testability
3. system efficiency
4. programmer efficiency
Justify your definitions and test them out on the code you and your partner produced for any of the pair programming exercises.
Ans : • maintainability
o For maintainability, one should reward behaviour that produces well-documented code that is neither too terse or too verbose. To this end, LOC should be divided into lines of documentation, total number of LOC, and lines of executable code. If there are many lines of executable code versus total LOC then this is probably complex code that should be very well documented and thus the number of documentation lines can be evaluated with this in mind.
• testability
o For testability, the most important LOC feature is the number of executable lines since this will give you an idea of the complexity of the code and thus the quantity of testing that will be needed. If number of executable lines can be further divided into number of "control" lines (if-then-else, switch, etc) then this measure of complexity and need for tests will be further enhanced.
• system efficiency
o For system efficiency, the most important LOC features are lines of execution versus lines of non-execution that are not comment lines. A large number of non-execution lines may be an indication of lots of memory allocations - this might be a sign of possible system efficiency problems - not guaranteed to be but worth a look.
• programmer efficiency
o For programmer efficiency, the LOC features to compare would be the ratio between executable lines, non-executable lines and comment lines. This should be in balance so that one does not dominant the others. Once again this is just a way to flag if a programmer has a distinctive propensity to be too verbose or too terse.
4. Compare the measurement of program size in the case of traditional procedural programming languages and in the case of object-oriented languages. Construct your answer in the following way:
• briefly describe how size is measured in procedural language programs
• briefly describe how size is measured in object-oriented language programs
• describe the similarities
• describe the differences
Limit your answer to 500 words.
5. Develop a project policy statement that uses lines of code and the quality metrics of your choice (i.e. equations that relate LOC to elements of quality such as productivity, maintainability, etc.) to motivate and reward team members.
Ans : Provide 4 examples to support your policy decisions and limit your answer to 100 words or less.
Policy: To produce extensible/reusable code, programmers will be advised to produce code that has the following properties:
• each logical segment of code (e.g. class, method, etc) will have a ratio of lines of documentation to lines of code of at least 1:10
• all logical segment of code should be of a similar size (+- 20%) with regards LOC
This policy will have the following effects:
1. encourage documentation but not too much documentation
2. encourage programmers to consider the size of their classes and methods and thus to review their design choices and code properties such as high cohesion and low coupling
3. since this policy will probably result in code that is highly compartmentalized and well designed, it will be easier to reuse
4. since each module will be appropriately documented this should also make reuse and extending more likely
6. Assume that you're the manager of a small project. What baselines would you define for the project and how would you control them?
Ans : A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. The baselines that I will define for the project are as under:
• Schedule baseline
• Cost baseline
• Scope baseline
• Development baseline
• Source code
• Test cases
• Design specification
• System specification
• Software requirements
As a project manager, I will ensure that all the baselines are being met accordingly and the software project is proceeding as desired. Software schedule will be monitored throughout the software development, and in case of any deficiencies, appropriate solution will be figured out. Cost is also a baseline for project. It can only be met in case the software requirements are easily understood and are complete. Source code needs also be checked through the development process and the bugs that are found will be fixed at appropriate time in order to deliver good quality product to end users.
2. What is the difference between an SCM audit and a formal technical review?
Answer.
1st version of the answer:
SCM Audit:
A software configuration audit complements the formal technical review by assessing configuration object for characteristics that are generally not considered during review.
Formal Technical Review:
The formal technical review focuses on the technical correctness of the configuration object that has been modified. The reviewers assess the SCI to determine consistency with other SCIs,omissions, or potential side effects. A formal technical review is the most effective filter from a quality assurance standpoint. Conducted by software engineers for software engineers, the FTRis an effective means for improving software quality.
No, the functions of SCM Audit and Formal Technical Review cannot be folded into one reviewbecause of the fact.
Formal Technical Reviews are used for improving software quality, whereas software configuration management audit is usually used to answer the questions that are indirectly related to software to achieve the desired quality. For example, we can perform formal technical reviews for coding, testing, debugging, etc., as these are directly related to the quality of the software, however, for SCM Audit, we will answer the questions which are not directly related to software quality rather indirectly. Some questions could be...
• Has the change specified in the ECO been made?
• Have any additional modifications been incorporated?
• Has a formal technical review been conducted to assess technical correctness?
• Has the software process been followed and have software engineering standards been properly applied?
• Has the change been "highlighted" in the SCI?
• Have the change date and change author been specified?
• Do the attributes of the configuration object reflect the change?
• Have SCM procedures for noting the change, recording it, and reporting it been followed?
• Have all related SCIs been properly updated?
• Besides above, in some cases questions are asked as part of a formal technical review. However,when SCM is a formal activity, the SCM audit is conducted separately by the quality assurance group.
