.png)
Mobiprep has created last-minute notes for all topics of Software Engineering to help you with the revision of concepts for your university examinations. So let’s get started with the lecture notes on Software Engineering.
7. UML
Our team has curated a list of the most important questions asked in universities such as DU, DTU, VIT, SRM, IP, Pune University, Manipal University, and many more. The questions are created from the previous year's question papers of colleges and universities.
Software Project Management
Question 1) Write five major responsibilities of a software project manager.
Answer) The five major responsibilities of a software project manager:
Planning: To complete a project in a specific manager should have an effective plan.
Scope: The project manager must clearly define the scope of the project and answer questions like, who is the customer? What need will the software satisfy? What are the operational requirements for the project?
Activity Schedules: Making activity schedules and planning out the activities according to the time frame is extremely important. He must first list out the jobs to be done and then allot specific jobs to team members.
Gantt Chart: Once the activities and different tasks have been outlined, the project manager lists the activities in Gantt chart and allot time frames for their completion.
Potential Risks: He must plan for any hindrances that might occur during the course of the project. Risk management is an integral part of the project and ensures the presence of a backup plan.
Setting Goals: He must set measurable goals that should define the overall project’s objective. For example: Complete the project within six months from start date in the budget of xxx amount. It is concise, crisp and outlines the objective clearly.
Time Management: Time estimation for the various activities is of major significance as it helps set the daily priorities of each team member. A project manager has to properly time all the activities for the completion of the project and also prepare for any delays in any of the activities.
Budget Allocation and Cost Estimates: Project manager must assign budgets to the various activities and make any cost considerations that there might be.
Implementation and Monitoring: Implementation of the project’s activities includes delegating different activities and ensuring their completion on time. Executing the plan of action and ensuring that it is monitored along the way is a key responsibility. A project manager must set out the project boundaries and scope for the project which then formulates itself into a plan of action and assists in successful completion of the project.
Question 2) What is meant by the ‘size’ of a software project?
Answer) Software size is the key factor to determine the planning activities of software development processes. For the successful completion of the software development process, perfect planning is necessary. During planning Software Size assessed, effort estimated in person hour or in person months, cost and budget calculated, schedule prepared, resources and work allocation process to be completed.
The software size is very important for perfect planning of the development process because Size is the base factor to determine effort, duration, schedule, cost and etc. that affect the development process. The sizing techniques followed in the industry are not covering all aspects of software so size and size-based parameters are leading difficulties in planning. Planning is the important Project management activity.
Question 3) What do you understand by sliding window planning?
Answer)
Project planning requires utmost care and attention since commitment to unrealistic time and resource estimates result in schedule slippage.
However, project planning is a very challenging activity. Especially for large projects, it is very much difficult to make accurate plans.
A part of this difficulty is due to the fact that the proper parameters, scope of the project, project staff, etc. may change during the span of the project. In order to overcome this problem, sometimes project managers undertake project planning in stages.
Planning a project over a number of stages protects managers from making big commitments too early. This technique of staggered planning is known as Sliding Window Planning.
In the sliding window technique, starting with an initial plan, the project is planned more accurately in successive development stages.
At the start of a project, project managers have incomplete knowledge about the details of the project. Their information base gradually improves as the project progresses through different phases.
After the completion of every phase, the project managers can plan each subsequent phase more accurately and with increasing levels of confidence.
Question 4) What do you understand by product visibility in the context of software development?
Product visibility refers to your products’ visibility on your storefront. When you make a product not visible, it will not appear on any category pages, search results or product panels (like New or Featured), and customers will not be able to access its product detail page. If you want to hide a product from category pages, but still have it be available via URL/direct link, see Limiting Product Accessibility.
There are several reasons why you might want to have a product not be visible:
A product may become temporarily unavailable.
While creating a new product, you might want to save and come back to it later before publishing it.
You want to add a product to a manual order, but not have it publicly available on the storefront.
Question 5) What are the different categories of software development projects according to the COCOMO estimation model?
Answer) COCOMO (Constructive Cost Estimation Model) was proposed by Boehm in 1981. It is a procedural software cost estimation model. It is basically a regression model based on the number of lines of code. COCOMO is also used to predict the parameters of a software project like size, effort, cost, time and quality.
According to Boehm, software cost estimation should be done through three stages: Basic COCOMO, Intermediate COCOMO, and Detailed COCOMO.
Basic COCOMO
The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions:
Effort = a1 х (KLOC)a 2 PM
Tdev = b1 x (Effort)b 2 Months
Where,
KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
a1, a2, b1, b2 are constants for each category of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Intermediate COCOMO
The basic COCOMO model assumes that effort and development time are functions of the product size alone. However, a host of other project parameters besides the product size affect the effort required to develop the product as well as the development time. Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account. The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development. In general, the cost drivers can be classified as being attributes of the following items:
Product: The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc.
Computer: Characteristics of the computer that are considered include the execution speed required, storage space required etc.
Personnel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc.
Development Environment: There attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development.
Detailed COCOMO
A major shortcoming of both the basic and intermediate COCOMO models is that they consider a software product as a single homogeneous entity. However, most large systems are made up of several smaller sub-systems. These subsystems may have widely different characteristics. The Detailed COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The cost of each subsystem is estimated separately. This approach reduces the margin of error in the final estimate.
The following development project can be considered as an example application of the complete COCOMO model. A distributed Management Information System (MIS) product for an organization having offices at several places across the country can have the following sub-components:
Database part
Graphical User Interface (GUI) part
Communication
Question 6) What are the popular metrics to measure project size?
Answer) Accurate estimation of the problem size is fundamental to satisfactory estimation of effort, time duration and cost of a software project. In order to be able to accurately estimate the project size, some important metrics should be defined in terms of which the project size can be expressed. The size of a problem is obviously not the number of bytes that the source code occupies. The project size is a measure of the problem complexity in terms of the effort and time required to develop the product. Currently two metrics are popularly being used widely to estimate size: lines of code (LOC) and function point (FP).
Lines of Code (LOC)
LOC is the simplest among all metrics available to estimate project size. This metric is very popular because it is the simplest to use. Using this metric, the project size is estimated by counting the number of source instructions in the developed program. Obviously, while counting the number of source instructions, lines used for commenting the code and the header lines should be ignored.
Determining the LOC count at the end of a project is a very simple job, but at the beginning of the project it is difficult. In order to estimate the LOC count at the beginning of a project, project managers usually divide the problem into modules, and each module into submodules and so on, until the sizes of the different leaf-level modules can be approximately predicted.
Function point (FP)
Function point metric overcomes many of the shortcomings of the LOC metric. One of the important advantages of using the function point metric is that it can be used to easily estimate the size of a software product directly from the problem specification. The conceptual idea behind the function point metric is that the size of a software product is directly dependent on the number of different functions or features it supports. Each function when invoked reads some input data and transforms it to the corresponding output data.
The size of a product in function points (FP) can be expressed as the weighted sum of these five problem characteristics. Function point is computed in two steps. The first step is to compute the unadjusted function point (UFP).
UFP = (Number of inputs)*4 + (Number of outputs) *5 + (Number of inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10
Once the unadjusted function point (UFP) is computed, the technical complexity factor (TCF) is computed next. TCF refines the UFP measure by considering fourteen other factors such as high transaction rates, throughput, and response time requirements, etc. Each of these 14 factors is assigned from 0 (not present or no influence) to 6 (strong influence). The resulting numbers are summed, yielding the total degree of influence (DI).
TCF = (0.65+0.01*DI).
Finally, FP=UFP*TCF.