1. Under which circumstances might the Lehman\'s laws break down? 2. Under which
ID: 3773747 • Letter: 1
Question
1. Under which circumstances might the Lehman's laws break down?
2. Under which circumstances might an organization decide to scrap a system when the system assessment suggests that it is of high quality and of high business value?
3. It seems odd that cost and schedule estimates are developed during software project planning-before detailed software requirements analysis or design have been conducted. Why do you think this is done and under which circumstances do you think this should not be done?
4. Do you think performance can be interpreted differently depending upon the software application area? Justify your answer.
Explanation / Answer
1)
1. Maintenance is inevitable – environment, error & enhancement
2. Changes degrade structure – ad hoc nature of changes
3. For large systems, early process constrains later development – organizational overhead & inertias
4. development rate is invariant - organizational overhead & inertias
5. Modification / release is invariant - more functionality <-> more faults bounds progress
6. Functionality increases – this is observable
7. Quality decreases – expected from ad hoc changes & complexity
8. Feedback is necessary for real improvement – takes an end user view seriously.
___________________________________________________________________________________________
2)
Examples of where software might be scrapped and rewritten are:
a) When the cost of maintenance is high and the organisation has decided to invest in new hardware. This will involve significant conversion costs anyway so the opportunity might be taken to rewrite the software.
b) When a business process is changed and new software is required to support the process.
c) When support for the tools and language used to develop the software is unavailable. This is a particular problem with early 4GLs where, in many cases, the vendors are no longer in business.
___________________________________________________________________________________________
3)
Estimation of cost, and schedule for a software engineering effort requiresexperience, access to good historical information, and the courage to committo quantitative predictions when qualitative information is all that exists.Estimation carries inherent risk1 and this risk leads to uncertainty.
This might be done because of the given below reasons:
Increases in project size can have a geometric impact on project cost andschedule.Risk is measured by the degree of uncertainty in the quantitative estimatesestablished for cost, and schedule. The planner, and more important, the customer should recognize thatvariability in software requirements means instability in cost and schedule.
___________________________________________________________________________________________
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.