Professional Documents
Culture Documents
Semester: 3rd
Spring 2011
Master in Business Administration-MBA SEM III MI0033 Software Engineering 4 Credits Assignment Set- 1 (60 Marks)
1. Discuss the Objective & Principles Behind Software Testing.
TESTING OBJECTIVES:
1. Testing is a process of executing a program with the intent of finding an error. 2. A good test case is one that has a high probability of finding an as yet undiscovered error. 3. A successful test is one that uncovers an as yet undiscovered error. Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications. The data collected through testing can also provide an indication of the software's reliability and quality. But, testing cannot show the absence of defect -- it can only show that software defects are present.
TESTING PRINCIPLES:
Before applying methods to design effective test c ases, a software engineer must understand the basic principles that guide software testing. 1. 2. 3. 4. All tests should be traceable to customer requirements. As we have seen, the objective of software testing is to uncover errors. It follows that the most severe def ects (from the customers point of view) are those that cause the program to fail to meet its requirements. Tests should be planned long before testing begins. Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated. The Pareto principle applies to software testing. Stated simply, the Pareto principle implies that 80 p ercent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them. Testing should begin in the small and progress tow ard testing in the large. The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system Exhaustive testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component -level design have been exercised. To be most effective, testing should be conducted by an independent third party. By most effective, we mean testin g that has the highest probability of finding errors (the primary objective of testing).
5.
6.
Name: Shailesh Kumar Registration Number: 511035200 Specialised Stream: Information Systems Management
not be able to repeat their past successes again. Software project success depends on having quality people. Level 2 - Repeatable
Semester: 3rd
Software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and sched ule. Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans. Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks). Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to re peat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimate. Level 3 - Defined The organizations set of standard processes, which is the basis for level 3, is established a nd improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organizations set of standard processes according to tailoring guidelines. The organizations management establishes process objectives based on the organizations set of standard processes and ensures that these objectives are appropriately addressed. A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, a nd procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organizations set of standard processes to suit a particular project or organizational unit. Level 4 - Managed Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. At this level organization set a quantitative quality goal for both software process and software mainten ance. Sub processes are selected that significantly contribute to overall process performance. These selected sub processes are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable. Level 5 - Optimizing Focusing on continually improving process performance through both incremental and innovative technological improvements. Quantitative process -improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organizations set of standard processes are targets of measurable improvement activities. Process improvements to address common causes of process variation and measurably improve the organizations processes are identified, evaluated, and deployed .
Name: Shailesh Kumar Registration Number: 511035200 Specialised Stream: Information Systems Management
Semester: 3rd
Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organizations ability to rapidly respond to changes and opport unities is enhanced by finding ways to accelerate and share learning. A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process -improvement objectives.
The Waterfall Software Life Cycle Model With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activit ies has some important consequen ces. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system. The consequence of the need of certification is that each phase must have some defined output that can be evaluated and certified. Therefore, when the activities of a phase are completed, there should be an output product of that phase and the goal of a phase is to produce this product. The outputs of the earlier phases are often called interm ediate products or design document. For the coding phase, the output is the code. From this point of view, the output of a software project is to justi fy the final program along with the use of documentation with the requirements document, design document, project plan, test plan and test results. Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified, the se outputs become the inputs to the next phase and should not be changed or modified. Ho wever, changing requirements cannot be avoided and must be faced. Since changes performed in the output of one phase affect the later phases that might have
Name: Shailesh Kumar Registration Number: 511035200 Specialised Stream: Information Systems Management
Semester: 3rd
been performed. These changes have to make in a controlled manner after evaluating the effect of ea ch change on the project. This brings us to the need for configuration control or configuration management. The certified output of a phase that is released for the best phase is called baseline. The configuration management ensures that any changes to a baseline are made after careful review, keeping in mind the interests of all parties that are affected by it. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model . For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product.
Name: Shailesh Kumar Registration Number: 511035200 Specialised Stream: Information Systems Management
COCOMO Model:
Semester: 3rd
COCOMO stands for constructive cost model. It is used for software cost estimation and uses regression formula with parameters based on historic data. COCOMO has a hierarchy of 3 accurate and detail forms, namely: Basic, Intermediate and Detailed. The Basic level is good for a quick and early overall cost estimate for the project but is not accurate enough. The intermediate level considers some of the other project factors that influence the project cost and the detailed level accounts for various project phases that affect the cost of the project. Advantages of COCOMO estimating model are: COCOMO is factual and easy to interpret. One can clearly understand how it works. Accounts for various factors that aff ect cost of the project. Works on historical data and hence is more predictable and accurate. Disadvantages of COCOMO estimating model 1. COCOMO model ignores requirements and all documentation. 2. It ignores customer skills, cooperation, knowledge and o ther parameters. 3. It oversimplifies the impact of safety/security aspects. 4. It ignores hardware issues 5. It ignores personnel turnover levels 6. It is dependent on the amount of time spent in each phase.
Estimating Software Schedule There are many tools on the market (such as Timeline, MacProject, On Target, etc.) which help develop Gantt and PERT charts to schedule and track projects. These programs are most effective when you break the project down into a Work Breakdown Structure (WBS), and assign estimates of effort and staff to each task in the WBS.
Name: Shailesh Kumar Registration Number: 511035200 Specialised Stream: Information Systems Management
Semester: 3rd
Software can work right at the first time We cannot expect software to work properly at the first time. For example, you go to an aeronautics engineer, and ask him to build a jet fighter; he will quote us the price. But if we demand it to be put into production without building its prototype, then he will r efuse the job. Software engineers are often asked to do that sort of work that is quite unexpected.
Software is easy to change Well, source code of the software is easy to edit, but is quite different from saying that it is easy to change. Because changes made in software without introducing problems are very difficult. Verification of the complete system is needed after every change. Therefore software is not easy to change and proper care is needed during every change.
Software with more features is a better software It is a totally false statement that software with more features is better software. Best software is that which does one task well.
Reusing Software increases safety Reusing software does not increase safety. Reusing code can helps in imp roving the development efficiency, but it needs a lot of analysis to check its suitability and testing to see if it works.
Addition of more software engineers will cover up the delay It is not true in all the cases. Sometimes, by adding more software engineers during the project, we may further delay the project. Therefore it is not true in our case, but adding more people can certainly cover up the delay in civil engineering work.
Software myths list is endless. Various other software myths are like c omputer provides greater reliability than the device they replaced; testing errors can remove the errors etc.