Cs605 software engineering crunt\
Ans: There are two basic risk management philosophies, reactive and proactive.
• Reactive – Indiana Jones school of risk management
– Never worrying about problems until they happened, and then reacting in some heroic way – Indiana Jones style.
• Proactive
– Begins long before technical work starts
– Risks are identified, their probability and impact are analyzed, and they are ranked by importance.
Ans:
The quality of the end result depends upon the quality of the intermediate work products.
If the requirements, design, code, and testing functions are of high quality, then the
chances are that the end product will also be of good quality. So, a good software
engineer would adopt mechanisms to measure the quality of the analysis and design
models, the source code, and the test cases.
Ans: A logical file cannot be counted as both an ILF and EIF for the same application. If the data group satisfies both rules, count as an ILF.
Mcqs 70 % from moiz file…
Subjective was….
1….Write at least one significance of statistical control technique ? 2 marks
Ans:To use data to analyze the results of process changes and their
impact on the time to implement change requests. In order to do that, we need to employ some statistical techniques and plot the result
graphically. This is known as statistical control techniques.
2…being a project manager you need to identify a scope of certain project ,but this type of application is taken 1sttime your company,which technique is used
For software scope correctly? 3 marks
Ans: Software scope describes the data and control to be processed, function, performance,
constraints, interfaces, and reliability. Determination of the software scope is a prerequisite of all sorts of estimates, including, resources, time, and budget.
In order to understand the scope, a meeting with the client should be arranged. The
analyst should start with developing a relationship with the client representative and start
with context-free questions. An understanding of the project background should also be
developed. This includes understanding:
• Who is behind the request (sponsor)?
• Who will use the solution (users)?
• What are the economic benefits (why)?
3…..Do you think that the buy approach always work as compared to build approach ,give reason? 5 marks
Ans: Buy versus build
It is often more cost-effective to acquire than to build. There may be several different
options available. These include:
• Off-the-shelf licensed software
• Software components to be modified and integrated into the application
• Sub-contract
The final decision depends upon the criticality of the software to be purchased and the
end cost. The buy versus build decision process involves the following steps:
• Develop specification for function and performance of the desired software.
Define measurable characteristics whenever possible.
• Estimate internal cost and time to develop
• Select 3-4 candidate applications that best meet your specifications
• Select reusable software components that will assist in constructing the required
application
• Develop comparison matrix that presents a head-to-head comparison of key
function. Alternatively, conduct benchmark tests to compare candidate software.
• Evaluate each software package or component based on past product quality,
vendor support, product direction, reputation, etc.
• Contact other users of the software and ask for opinion.
4….In software application having same size in function point unit may have different
Line of code,give reason? 5 marks
…………………….
Q. List at least one advantage of using statistical control techniques in software engineering (2 marks)
Ans: Any one you can pick
1) It provides a means of detecting error at inspection.
2) It leads to more uniform quality of production.
3) It improves the relationship with the customer.
4) It reduces inspection costs.
5) It reduces the number of rejects and saves the cost of material.
6) It provides a basis for attainable specifications.
7) It points out the bottlenecks and trouble spots.
2)
Q. Suppose a project to consist of three components i.e.
Login- Component, Filter- Component, Transfer- Component.
Calculate the overall Projects system complexity from the following data (5 marks)
Component / Structural Complexity / Data ComplexityLogin- Component / 1 / 1
Filter- Component / 2 / 1
Transfer- Component / 1 / 1
Ans:
The quality of the architectural design can be measured by measuring its complexity as
shown below:
– Structural complexity S = (fout)2
– Data complexity D = v/(fout + 1)
• ‘v’ is the number of input and output variables
– System complexity C = ∑ (Si + Di)
Here formulas…. But question ksy krna ha pta nahi
Cs605
1.for external user point of view which technique is used 2
2. Two characteristics of Risk 2
Ans:
risk with the following characteristics:
• Risk rj - High turnover
• Likelihood lj = 0.7
• Impact xj - projected at level 2 (critical)
3. suggest the reason behind performing feasibility assessment of project. 3
Ans:
The purpose of the feasibility analysis is to determine can we build software to meet the
scope? For this purpose, the project is analyzed on the following 4 dimensions:
1. Technology
2. Finance
3. Time
4. Resources
4. Guideline for increasing maintainability at Design level. 3
5. identify some DETs 5
Ans:
DET Definition
A data element type is a unique user recognizable, non-repeated field.
DET Rules
The following rules apply when counting DETs:
1. Count a DET for each unique user recognizable, non-repeated field maintained in or
retrieved from the ILF or EIF through the execution of an elementary process.
2. . When two applications maintain and/or reference the same ILF/EIF, but each
maintains/references separate DETs, count only the DETs being used by each
application to size the ILF/EIF
3. Count a DET for each piece of data required by the user to establish a relationship
with another ILF or EIF.
6.can we ensure 100% risk free software development. Comment with reasons 5
Ans:
No we can not ensure 100% risk free software development.
Legacy system migration however is not an easy task and there are a number of risks
involved that need to be mitigated. First of all, there is rarely a complete specification of
the system available. Therefore, there is no straight forward way of specifying the
services provided by a legacy system. Thus, important business rules are often embedded in the software and may not be documented elsewhere. Business processes and the way
legacy systems operate are often intertwined. New software development may take
several years.
New software development is itself risky as changes to one part of the system inevitably
involve further changes to other components.