AKGEC/ IAP/FM/01 REV N0: 00

AJAY KUMAR GARG ENGINEERING COLLEGE, GHAZIABAD University Test COURSE: B.Tech(CSE) SUB: Software Project Management MM : 100 SECTION: A/B SUB CODE: ECS-082 TIME: 3Hr

Q1. Attempt any TWO [2X10=20] a) Why the process of project planning is iterative and why a plan must be continually reviewed during a software project? Describe with an example. Solution: In software systems development, iterative project planning adds agility to the development process by allowing the developers as well as the users to learn from, and build upon former software development projects. In particular, iterative development reduces development risks such as poorly defined user requirements; untenable architectures as well as untenable user interfaces. Iteration is defined as the process of repeating something as often as is necessary until a specific result is achieved. This certainly holds true when defining the exact user requirements of a computerized system before the design and development stages begin. It is often stated that if you can find an error or an oversight during the requirements definition stage, you can fix it with an eraser and a pencil. Finding the same mistake once the system has become operational, can be costly in several ways. A project plan is analogous to a road map that not only shows you how to get from point A to point B; but also lists various milestones along the way. A project plan is similar to a road map with the exception that it also includes the "what" and the "when" with respect to certain project resource requirements as well as their critical paths. A project plan must be continuously monitored to as to determine, at any point in time during the project, if the planned progress of the project corresponds with the actual progress of the project. A discrepancy can be the result of poor planning and/or the introduction of one or more factors during the project that were unforeseen during the project planning phase. If such a discrepancy exists, it must be intercepted at the earliest point in time possible so that immediate corrective actions can be taken, thus minimizing the possibility that the project will not be completed on time and/or within the allocated budget.

b) (i) Explain why the intangibility of software system possess special problems for software project management? (ii) Discuss the various responsibilities of a software project manager. Solution: (i) Software under development is considered and Intangible Asset and requires special accounting procedures. Since you can not see it, touch it, stand on it or eat it, you have to rely on your team to produce timely and accurate documentation needed to track progress and productivity. The intangible nature of software causes problems for management in planning, estimating, scheduling and budgeting for accounting purposes. Ensuring that the software is delivered on schedule and in accordance with the the projects requirements. Project management is needed because software development is subject to problems in development, flexible budgets and schedule constraints. The software project managers job is to ensure that the software project meets these constraints on time and within projected investment calculations. From an accounting view which I see as the biggest obstacle, intangible assets have special guidelines for capitalization. Computer software is the most common type of an internally generated intangible asset. It can be purchased or licensed from a 3rd party and then modified it is still considered internally generated and re-classified as an intangible asset. The cost of internally generated intangibles, such as computer software, must be capitalized or expensed depending on three project stages:1) Preliminary project stage -formulation and evaluation of alternatives, determining the existence of the needed technology. 2) Application development design includes coding, installation to hardware, testing, and parallel processing. 3) Post-implementation stage includes application training and software maintenance. Stages 1 and 3 are expensed, while stage 2 is capitalized. Generally, you have not reached stage 2 until you have executive management support for the project along with a commitment of funding and personnel. Determining what stage you are in can be difficult for large projects. Large projects might need to be broken down into multiple modules which are capitalized separately. The people involved in designing a software project are its greatest assets. They represent intellectual capital and its up to the software project manager to get best out of their investment in people. This is achieved when people are respected by their company and given a level of responsibility and reward that matches their skills. Software Project management is about regulating and managing phases of development done by others on a product that you can't see, smell, touch or eat and you can't even demonstrate it until it's almost finished. A close working relationship and constant communication with the people you are relying on to get the job completed are your greatest tools. (ii) Responsibility of a project Manager: Those are the following responsibilities which project manager should take part: 1.Project /Practice Management

Creates and executes project work plans and revises as appropriate to meet changing needs and requirements. Identifies resources needed and assigns individual responsibilities. 2

Manages day-to-day operational aspects of a project and scope. Reviews deliverables prepared by team before passing to client. Effectively applies our methodology and enforces project standards.

2. Project Accounting

Tracks and reports team hours and expenses on a weekly basis. Manages project budget. Determines appropriate revenue recognition, ensures timely and accurate invoicing, and monitors receivables for project. Analyzes project profitability, revenue, margins, bill rates and utilization.

3. Financial Management

Understands basic revenue models, P/L, and cost-to-completion projections and makes decisions accordingly. Understands our pricing model and billing procedures. Accurately forecasts revenue, profitability, margins, bill rates and utilization. Assures project legal documents are completed and signed.

4. Business Development

Identifies business development and "add-on" sales opportunities as they relate to a specific project. Effectively conveys our message in both written and verbal business development discussions.

5. Communication

Facilitates team and client meetings effectively. Effectively communicates relevant project information to superiors. Delivers engaging, informative, well-organized presentations. Resolves and/or escalates issues in a timely fashion.

6. Technical Understanding

Understands Internet, Intranet, Extranet and client/server architectures. Possesses a thorough understanding of our capabilities. Maintains awareness of new and emerging technologies and the potential application on client engagements.

c) Is software project estimation essential for all kinds of software projects? Discuss various software estimation techniques. Solution: Yes. Software project planning actually encompasses all estimation, risk analysis, scheduling, and planning. However, in the context of set of resources, planning involves estimation - your attempt to determine how much money, how much effort, how many 3

resources, and how much time it will take to build a specific software-based system or product. The following topic categories are presented Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on a project. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.
Parametric Estimating-Estimation theory is a branch of statistics and signal processing that deals with estimating the values of parameters based on measured/empirical data that has a random component. For example, it is desired to estimate the proportion of a population of voters who will vote for a particular candidate Wideband Delphi -The Wideband Delphi estimation method is a consensus-based technique for estimating effort. It derives from the Delphi Method which was developed in the 1940s at the RAND Corporation as a forecasting tool. It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts. COCOMO- The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics. SLIM The Putnam model is an empirical software effort estimation model. As a group, empirical models work by collecting software project data (for example, effort and size) and fitting a curve to the data. Future effort estimates are made by providing size and calculating the associated effort using the equation which fit the original data (usually with some error). SEER-SEM-Parametric Estimation of Effort, Schedule, Cost, Risk. Mimimum time and staffing concepts based. SEER for Software (SEER-SEM) is an algorithmic project management software application designed specifically to estimate, plan and monitor the effort and resources required for any type of software development and/or maintenance project. Proxy-based estimating (PROBE ) (from the Personal Software Process) PROxy-Based Estimating (PROBE) is an estimating process used in the Personal Software Process (PSP) to estimate size and effort. Proxy Based Estimating (PROBE), is the estimation method introduced by Watts Humphrey (of the Software Engineering Institute at Carnegie Mellon University) as part of the Personal Software Process (a discipline that helps individual software engineers monitor, test, and improve their own work). The Planning Game (from Extreme Programming) Extreme programming (XP) is a popular agile software development methodology used to implement software projects. The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:

Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. o Iteration Planning: This plans the activities and tasks of the developers. Program Evaluation and Review Technique (PERT) The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project. It is commonly used in conjunction with the critical path method or CPM. Analysis Effort method The analysis effort method is a method for estimating the duration of software engineering projects. It is best suited to producing initial estimates for the length of a job based on a known time duration for preparing a specification. Inputs to the method a numeric factors which indicate Size (S), Familiarity (F) and Complexity (C). Evidence-based Scheduling Refinement of typical agile estimating techniques using minimal measurement and total time accounting. Evidence-based Scheduling is a software estimation approach created by Joel Splashy, a commentator on software engineering principles.
o

Q2. Attempt any TWO [2X10=20] a) What is the purpose of Activity Network? The following figure set out a number of activities, duration, and dependencies. Draw an activity chart and bar chart showing the project schedule:Tasks T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 Solution: A project is composed of a set of actions or tasks which usually have some kind of interdependency. For example, before an axle can be turned, it must first be designed, the metal must be purchased, etc. This type of complex system is much easier to understand 5 Activity (in days) 10 15 10 20 10 15 20 35 15 5 10 20 35 10 20 10 duration Dependencies T1 T1,T2 T3, T4 T3 T7 T6 T5,T9 T9 T10 T3,T4 T8,T9 T12, T14 T15

through the use of diagrams than through textual description, as actual interconnections between tasks can be shown. The Activity Network diagram displays interdependencies between tasks through the use of boxes and arrows. Arrows pointing into a task box come from its predecessor tasks, which must be completed before the task can start. Arrows pointing out of a task box go to its successor tasks, which cannot start until at least this task is complete.

Fig. 1. The Activity Network Diagram

The Activity Network can be used to identify risk in the plan. Typical areas where there is a danger of the schedule being slipped include:

Anywhere on the critical path. Where there is a long sequence of tasks, each with a single predecessor and successor. If any task is delayed, it will delay all of its successor tasks. Also, a small risk of delay for each task adds up to a large delay for the overall task sequence. Where a task has many predecessors. If any one predecessor task is delayed, then the task will also be delayed. When a resource or person that may become unavailable is used in any of the above situations, the risk is compounded. Where there are many tasks running at one time, particularly if there are several risky ones. A risk here is that management will not be able to cope with simultaneous failure.

Risks in the Activity Network The solution is below:

b) (i) Discuss various steps for building a project schedule with an example. (ii) Write short notes on product life cycle. Solution: (i) Building a schedule Building a schedule is the process of deciding how to distribute resources between the required work and setting start and due dates of the project work items. This process is usually performed by the project manager or a person assigned to fulfill the role of the 7

project manager in the context of initially creating the work plan. Project schedule is usually fine tuned by the project team at later stages of project execution. To build the project schedule you will need to provide information on: Step One: Define Activities The goal of the activity definition step is to identify all the tasks required to accomplish the product. This frequently results in identifying all the work products and deliverables that comprise the project. These deliverables are found as the components of a Work Break Down structure (WBS). The project schedule further decomposes these deliverables into the actual activities required to complete the work. Step Two: Sequence Activities At this point you've entered all the task names and have further decomposed the deliverables listed in the WBS. The next step is to sequence the activities with dependencies. During this step, you'll identify any dependencies of related tasks and document them in the project schedule. You'll need to analyze each of the tasks to understand which task has a dependency on additional tasks. In your favorite project schedule development book, be sure to read about the different types of dependency relationships include Finish-to-Start and Start-to-Start dependencies. These relationships will impact your task start and finish dates. Step Three: Estimate Activity Resources The next step is to identify the resources and their availability to your project. Remember that not all team members will be 100% available to your project as some team members will be working on multiple projects. In this step, you'll also assign resources to each of the tasks. Step Four: Estimate Activity Durations With resources assigned, the next step is to estimate each task's duration. The activity's duration is the number of working periods required to complete the task. In Microsoft Project, this can be defined in days, weeks, and even months! It is also important to understand the difference of the different duration types including Fixed Work, Fixed Duration and Fixed Units. Selecting the correct duration type impacts the resource availability and the forecasted task end date. Step Five: Develop Schedule The next step is to analyze the project schedule and examine the sequences, durations, resources and inevitable scheduling constraints. The goal of this step is to validate the project schedule correctly models the planned work. In this step you'll not only validate the duration estimates are accurate, but validate the resource allocations are correct. (ii) Product Life Cycle:The conditions a product is sold under will change over time. The Product Life Cycle refers to the succession of stages a product goes through. Product Life Cycle Management is the succession of strategies used by management as a product goes through its life cycle. 1. Introduction stage cost high sales volume low no/little competition - competitive manufacturers watch for acceptance/segment growth losses 8

demand has to be created customers have to be prompted to try the product

2. Growth stage costs reduced due to economies of scale sales volume increases significantly profitability public awareness competition begins to increase with a few new players in establishing market prices to maximize market share 3. Mature stage Costs are very low as you are well established in market & no need for publicity. sales volume peaks increase in competitive offerings prices tend to drop due to the proliferation of competing products brand differentiation, feature diversification, as each player seeks to differentiate from competition with "how much product" is offered very profitable 4. Decline or Stability stage costs become counter-optimal sales volume decline or stabilize prices, profitability diminish profit becomes more a challenge of production/distribution efficiency than increased sales c) Write short notes on : (i) Potential uses of Work Breakdown structure (WBS) (ii) Software project team organization Solution: (i) Potential uses of Work Breakdown structure (WBS):Why do we need to create a WBS for our projects? What purpose does it serve? Why should I waste my time writing on post-it notes and drawing charts when I could be getting my team started on the actual work of the project? Now, I know everyone reading this is a great project manager or team member, so I am sure none of you have ever said comments such as these, but I am sure you have heard them from those "other" project managers who will remain nameless. So to answer these questions, let's take a look at what purpose the WBS serves to our project and our project team. There are three reasons to use a WBS in your projects. The first is that is helps more accurately and specifically define and organise the scope of the total project. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more 9

specific and measurable chunks. The second reason for using a WBS in your projects is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it allows you double check all the deliverables' specifics with the stakeholders and make sure there is nothing missing or overlapping. (ii) Software project team organization:A project organization is a temporary thing. It will only exist from the projects start until its end. All the project team members are coming from different organizations of part of the organization. They will all have a temporary assignment to the project. So, they have not only a project boss (the project manager, that might be you), but also their 'normal' boss, who orders him around when the employee is not in the project. These 'normal bosses' are an important group of stakeholders. The project organization should be a result from the project strategy, it should be constructed in such a way that the strategy can be implemented within the environment of the project ("look what the dog brought in, a presumptuous sentence"). A very obvious example: if the strategy contains an aspect of having independent reviews, the organization should support its independence, by creating a separate working group with no ties to the other team members, e.g. But, I'm a little too far now mentioning working groups and the like. The project team that does the work should be as small as possible. Small is beautiful, and effective. Don't start inviting everyone to the organization. Only people who have an added value and will spend a significant amount of time to the project can be in the core organization. Try to avoid going overboard on working groups. Working groups can drown a project in communication overhead. If there should be that much discussion anyway, postpone the project and first make up the minds. Next to the people who do the work, are the people that have some influence on it, but do nothing; a large part of the stakeholders. The project organization can be used to satisfy some wishes of stakeholders to create the much needed win-win situations. In its most simple form, you can create a project trashcan ("The Project Tactical Non-Binding Advisory Committee") where you put in the people who just want to be involved in the project (to save their territory), but which you have no use for. Be creative while constructing the project organization. Take the Bob Ross way to paint your organization: "This is a sweet little project staff. I put it here next to the tracking and control group, so it has a friend." Q3 Attempt any TWO [2X10=20] a) Why project monitoring and control is needed for successful implementation of software project? Discuss various dimensions of project monitoring and control. 10

Solution:
Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.

Monitoring and Controlling Process Group Processes Monitoring and Controlling includes: Measuring the ongoing project activities ('where we are'); Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline ( where we should be); Identify corrective actions to address issues and risks properly ( How can we get on track again); Influencing the factors that could circumvent integrated change control so only approved changes are implemented In multi-phase projects, the monitoring and controlling process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan.

Dimensions of Project monitoring and control:The three values are: Budgeted Cost of Work Performed (BCWP). Budgeted Cost of Work Scheduled (BCWS). Actual Cost of Work Performed (ACWP). Definition of the Three Basic Values BCWP or Budgeted Cost of Work Performed or Earned Value This is the cost originally budgeted to accomplish the work that has been completed as of the analysis date. It answers the question how much work has actually been completed?. 11

BCWS or Budgeted Cost of Work Scheduled or Plan This is the total budgeted cost up to the analysis date. It answers the question how much did we plan to spend as of this date? A variant of this question is how much work should have been completed by this date? BCWS can be computed from the projects plans, as illustrated in the sequel, or it can be approximated by multiplying the total budget by the fraction of total project duration at the analysis date. Thus, for example, if the project budget is $100 and 20% of the projects time has elapsed, the approximate BCWS is $20. ACWP or Actual Cost of Work Performed This is what it actually cost to accomplish all the work completed as of the analysis date. It answers the question how much have we actually spent?. This is usually determined from the organizations accounting system, or can often be approximated by multiplying the number of people by the number of hours or days or weeks worked. b) (i) What is the significance of Schedule performance Index(SPI)? Discuss with example. (ii) Write a short notes on walkthroughs. Solution: (i) Schedule Performance Index (SPI index) : Represents how close actual work is being completed compared to the schedule. SPI is computed by EV / PV. A value of above one means that the project is doing well against the schedule. Schedule Performance Index (SPI) measures the progress achieved against that which was planned. SPI is calculated as EV/PV. If EV is equal to PV the value of the SPI is 1. If EV is less than the PV then the value is less than 1, which means the project is behind schedule. If EV is greater than the PV the value of the SPI is greater than one, which means the project is ahead of schedule. A well performing project should have its SPI as close to 1 as possible, or maybe even a little under 1. SPI = BCWP / BCWS (where BCWS is the budgeted cost of work scheduled).
Example 1 Suppose you have a budgeted cost of a project at $900,000. The project is to be completed in 9 months. After a month, you have completed 10 % of the project at a total expense of $100,000. The planned completion should have been 15 %. Now, lets see how healthy the project by computing the CPI index and SPI index. Solution : From the scenario, you can extract the following: BAC = $900,000 AC = $100,000 The Planned Value (PV) and Earned Value (EV) can then be computed as follows: Planned Value = Planned Completion (%) * BAC = 15 % * $ 900,000 = $ 135,000 Earned Value = Actual Completion (%) * BAC = 10 % * $ 900,000 = $ 90,000 Compute the earned value variances:

12

Cost Performance Index (CPI index) = EV / AC = $90,000 / $100,000 = 0.90. This means for every $1 spent, the project is producing only 90 cents in work. Schedule Performance Index (SPI index) = EV / PV = $90,000 / $135,000 = 0.67. This means for every estimated hour of work, the project team is completing only 0.67 hours (approximately 40 minutes). Interpretation: Since both Cost Performance Index (CPI index) and Schedule Performance Index (SPI index) are less than 1, it means that the project is over-budget and behind schedule. This example project is in major trouble and corrective action needs to be taken.

(ii) Software Walkthrough:In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed, its lack of a direct focus on training and process improvement, and its mission of process and product measurement. In general, a walkthrough has one or two broad objectives: to gain feedback about the technical quality or content of the document; and/or to familiarize the audience with the content. A walkthrough is normally organized and directed by the author of the technical document. Any combination of interested or technically qualified personnel (from within or outside the project) may be included as seems appropriate.

When should a walkthrough be held?

Informal ones tend to occur early Formal ones tend to occur late Schedule several Early enough so that the producer has not yet invested too much ego Late enough that the product is sufficiently well developed and documented to make some sense

Benefits

Find errors, quickly and economically Increase programmer productivity Reduce maintenance effort Spot gross design or implementation inefficiencies Establish standards for analysis, design, coding, testing, and documentation Training Insurance that work can be salvaged if someone leaves

13

c) Describe the characteristics of a good software metrics. Also discuss various software metrics for project monitoring. Solution: We use metrics as a basis to make decisions on and focus our actions. To be effective and reliable, the metrics we decide to use need to have five key characteristics. Each Software metric must be: 1. Aligned with business: In a Corporate Leadership Council survey, 62 percent of respondents cited to better align HR strategy with corporate strategy as the number-one goal for HR. More than half the respondents in a Towers Perrin study considered shifting HRs role to help address critical business issues as the most significant challenge for HR leadership. Clearly, HR alignment with business goals is a priority to measure and improve upon, but it is also difficult to achieve. First, corporate business targets (direction set by the CEO) and HR strategies need to be synchronized, and then translated into the tactics HR implements. 2. Actionable and predictive: A good metric must provide information that can be acted upon. Too often, HR measures for the sake of measuring, without really thinking, What do I do if the metric is lower or higher? A clear plan of action and causality relation is a key element for successful metrics tracking. A metric that merely measures finite or completed actions, not ongoing activity, is only of forensic interest. Metrics must be regarded as a trend and must trigger appropriate action. The issue with many data points is that they are usually lagging indicators in other words, they show what happened in the past. A metric that, when analyzed, can forecast the direction actions should take in the future is called a leading indicator. Presenting leading indicators that can drive aligned action is where strategic HR is going. 3. Consistent: A good metric is consistent in what it measures. Comparisons are made of equally weighted criteria. Cost per hire, for instance, has been a popular HR metric. Yet a SHRM/EMA Staffing Metrics study identified more than a dozen components included at widely varying degrees by different companies to calculate cost per hire. Make sure that the data included in any metric you use is defined at the outset and remains consistent. Otherwise, the value of its comparison is useless. 4. Time-trackable: A good metric must be able to be tracked over time. It is not a snapshot of an activity at one moment in time. One example is the number of job applications received per week. That metric can be tracked and graphed to see both the weekly trend, as well as a monthly, quarterly, or longer interval, and forecast whether there will be a shortage or not. The frequency of reporting for a metric varies with different metrics. We recommend that the time-to-fill metric, for instance, should be reported weekly. Metrics addressing longer-term evaluations, such as hiring manager satisfaction or new-hire performance, could be tracked quarterly or annually. 5. Peer comparisons: In addition to analyzing internal performance, good metrics should be able to be compared to external benchmarks among a peer group. That peer group may be another business unit within your company, another company 14

similar in size or location, for instance, or an industry benchmark. A metric viewed only as an internal measure may not reveal the need for improvement until tracked against an external benchmark. Conversely, that metric may show superior performance when viewed in a wider context. A good peer comparison metric allows for additional analysis of benchmark performance. Benchmarking by quartile can be another beneficial indicator of relative performance.

Various Software Project Metrics

There is a way to provide a project management status report. As an analogy, think about the criteria that a doctor might use to monitor health. He or she checks pulse, temperature, blood pressure etc. Similarly, a project needs to measure a mix of criteria. If you distill the ground covered in methodologies and literature on Project Management, there are six criteria that constantly emerge. They are: o Time (How are we going against schedule) o Cost (How are we going against budget) o Resources (How much time are we spending on the project) o Scope (Is the scope creep in line with expectations) o Quality (Are we reviewing and fixing quality problems) o Actions (Do we have action items outstanding) By looking at the performance against these six criteria as a project dashboard, a view of the parts of the project that are OK and the parts that are not OK can be formed.

- Project Time Line

The most common tool for managing a project is the schedule. Are we on time? At any point in a large project, there will probably be one or two tasks behind schedule and an equal number ahead of schedule. By setting parameters as to the number over schedule for the traffic lights to change, you can present the performance against schedule as a set of lights.

- Project Cost Management

It is not sensible to monitor budget in total. If the budget were spent half way through a project, we would suddenly be in trouble with no warning that the problem was occurring. For this reason, we need to create a project cash flow for the budget. Typically this is our estimate month by month of expenditure.

- Project Resources
Just as we have a cash flow for money, we can do a project human resource projection. To do this we need to estimate how many man-days per period will be used on the project. By comparing that to timesheets, we can work out if we are spending more or less time on the project than estimated. This technique does not measure trade off's regarding the quality of the resources. The quality will be largely covered by the budget. If less skilled resources are allocated to the project, the cost will be lower and consequently the expenditure against budget will be 15

less. It may however require longer to complete the work, or more resources may be needed.

- Project Scope Management

Every project will have some scope changes. A weakness in most project scope management is that scope changes are not monitored. Approval is often verbal and not recorded. A better way is to admit the blindingly obvious at the planning stage - there will be scope changes, and we need to allow for them. The next step is to put in place a tracking system with approvals. At the start of the project, estimate how much scope increases are likely to be as a percentage of the estimated budget, and as each increase is approved, monitor the total scope creep.

- Project Quality Management

It would be wonderful if we could create a magical program that looked at deliverables and reported on quality. Unfortunately, that will have to wait for technology to make a quantum leap. We do however have to produce a quality plan for the project.

- Project Action Items

The final parameter is Action Items outstanding. Many situations in a project generate action items. They could be generated by identification of a benefit. There needs to be an action item to follow up the benefit delivery. It could be generated by a risk where certain actions are required to mitigate the risk. It could be an issue that needs action items to resolve. It could be a project review where actions on recommendations are to take place.

Q 4. Attempt any TWO [2X10=20] a) Why is software testing is required? Explain. Discuss the difference between worst case and adhoc test case performance evaluation by means of testing. How can we be sure that the real worst case has actually been observed? Explain. Solution:

16

Why is software testing required?

Let us understand as to why software testing is required. Why can we just not avoid it? Would it not be nice if we did not have to test any software at all? Well, let us see! Firstly, the software development team is also composed of human beings and 'To err is human', thus any software product, irrespective of the competence level of the team developing it, can not be assumed to be free of defects. In order to remove those defects, we first need to identify them, right? That is exactly why testing is required. If we miss out on defects in any product (Always remember that testing can never ensure the absence of defects), what would happen? Would it have really serious consequences? Let us see! Let us consider another example. Have you ever traveled by air? How does the pilot charter the aircraft through dense clouds and high mountains? He is guided in these activities by the instrument panel in front of him. Further, these instruments are controlled by complex software embedded in them. So, we know that there are a variety of applications, which are controlled through software, and whose improper functioning can lead to huge losses of life/property. It is precisely to prevent losses like these that it is mandatory to test software. Let us consider another example. How about a banking product? Let us suppose that a bank is supposed to pay interest @ 5% per annum to all its customers, who have opened savings accounts with it. Now, what would happen if this software was not tested and the interest rate was inadvertently specified to be 50% per annum? Individual account holders might make a fortune for a while but the bank will soon go bankrupt. Now, consider the reverse case. What would happen if the interest rate got stored as 0.5% per annum? In this case, individual customers will lose initially and the bank might not even know about this bug till someone points it out. On the basis of all these examples, we can easily understand the significance of software testing. In fact, the importance of software testing can not be overemphasized. In Adhoc testing we test the software randomly and in this testing test cases are required.but in exploratory testing we test the software randomly there is no need of test cases.this is the main difference.

b) (i) Differentiate between integration testing and system testing with some example. (ii) Consider a program to determine whether a number is odd or even and print the message: NUMBER IS EVEN or NUMBER IS ODD. The number may be any valid integer. Design boundary value and equivalence class test cases. Solution: (i) Integration testing 17

Integration testing, also known as integration and testing (I&T), is a software development process which program units are combined and tested as groups in multiple ways. In this context, a unit is defined as the smallest testable part of an application. Integration testing can expose problems with the interfaces among program components before trouble occurs in real-world program execution. Integration testing is a component of Extreme Programming (XP), a pragmatic method of software development that takes a meticulous approach to building a product by means of continual testing and revision. System Testing System testing is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole. System testing is actually done to the entire system against the Functional Requirement Specification(s) (FRS) and/or the System Requirement Specification (SRS). Moreover, the system testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and test not only the design, but also the behaviour and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specification(s). (ii) Program # include<stdio.h> #include<conio.h> void main() { int a; clrscr(); printf("Enter the number: "); scanf ("%d", &a); if(a%2==0) { printf("\n Number is Even"); } if(a%2!=0) printf("\n Number is Odd"); 18

getch() } For Boundary value test cases we consider 0, even and odd values.

c ) Discuss the SEI Capability Maturity Model(CMM) in detail. Solution: SEI Capability Maturity Model(CMM):Maturity model A maturity model is a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model can be used as a benchmark for assessing different organizations for equivalent comparison. The model describes the maturity of the company based upon the project the company is handling and the related clients. Levels of CMM: Level 1 - Initial

At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects. Level 2 - Repeatable

At maturity level 2, some software development processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule. Process discipline is unlikely to be rigorous, but where it exists it may help to 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. 19

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 repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates. Level 3 - Defined

The organizations set of standard processes, which are the basis for level 3, are established and subject to some degree of improvement over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by applying the organizations set of standard processes, tailored, if necessary, within similarly standardized guidelines. The organizations management establishes process objectives for 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, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on each 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 process metrics, management can effectively control the process (e.g., for software development). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organizations at this level set quantitative quality goals for both software process and software maintenance. 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 may be quantitatively predictable. At maturity level 3, processes are only qualitatively predictable. 20

Level 5 - Optimizing and innovative technological improvements. Quantitative process-

Maturity level 5 focuses on continually improving process performance through both incremental 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.

Q5.

Attempt any TWO [2X10=20] a) What do you mean by software configuration? Explain. Why an attribute based version identification system makes it easier to discover all the components making up a specific version of a system? Discuss.

Solution: Configuration management (CM) is the process of controlling and documenting change to a developing system. It is part of the overall change management approach. As the size of an effort increases, so does the necessity of implementing effective CM. It allows large teams to work together in a stable environment while still providing the flexibility required for creative work . CM in a software environment is an absolute necessity. CM has three major purposes : 1. Identify the configuration of the product at various points in time. 2. Systematically control changes to the configuration. 3. Maintain the integrity and traceability of the configuration throughout the product life cycle. CM accomplishes these purposes by answering and recording the answers to the change questions: who, what, when, and why, shown in Figure 1 . Being able to answer these questions is a sign of effective CM.

21

Figure 1: Configuration Management Questions Effective CM provides the following essential benefits to a project: 1. Reduces confusion and establishes order. 2. Organizes the activities necessary to maintain product integrity. 3. Ensures correct product configurations. 4. Limits legal liability by providing a record of actions. 5. Reduces life-cycle costs. 6. Enables consistent conformance with requirements. 7. Provides a stable working environment. 8. Enhances compliance with standards. 9. Enhances status accounting. In short, CM can provide cost effective project insurance when properly planned, organized, and implemented. It must be integral to your overall project execution, and to your charter/customer agreement. Proposed changes must be dealt with systematically, promptly, and honestly . If the CM process is unreasonable or unresponsive, people will try to circumvent the process, leading to chaos and a loss of the benefits of true CM.
Functions of Configuration Management

CM is comprised of four primary functions: identification, change control, status accounting, and auditing. These are shown in Figure 2, along with their sub functions. All CM activity falls within the bounds of these functions.

22

Figure 2: Major Functions of Configuration Management (Click on image above to show full-size version in pop-up window.) Identification This function identifies those items whose configuration needs to be controlled, usually consisting of hardware, software, and documentation. These items would probably include such things as specifications, designs, data, documents, drawings, software code and executables, components of the software engineering environment (compilers, linkers, loaders, hardware environment, etc.), and hardware components and assemblies Change Control Configuration control establishes procedures for proposing or requesting changes, evaluating those changes for desirability, obtaining authorization for changes, publishing and tracking changes, and implementing changes. This function also identifies the people and organizations who have authority to make changes at various levels Status Accounting Status accounting is the documentation function of CM. Its primary purpose is to maintain formal records of established configurations and make regular reports of configuration status. These records should accurately describe the product, and are used to verify the configuration of the system for testing, delivery, and other activities. Auditing Effective CM requires regular evaluation of the configuration. This is done through the auditing function, where the physical and functional configurations are compared to the documented configuration. The purpose of auditing is to maintain the integrity of the baseline and release configurations for all controlled products . Auditing is accomplished via both informal monitoring and formal reviews

23

b) (i) What are risk management activities? Is it possible to prioritize the risks? Discuss. (ii) Write a short note on change request management. Solution: (i) Risk Management Activities:Risk identification, Risk analysis, Risk planning, Risk monitoring 24

Risk identification,Determining what risks or hazards exist or are anticipated, their characteristics, remoteness in time, duration period, and possible outcomes. Risk analysis is the process of defining and analyzing the dangers to individuals, businesses and government agencies posed by potential natural and human-caused adverse events. In IT, a risk analysis report can be used to align technology-related objectives with a company's business objectives. A risk analysis report can be either quantitative or qualitative. Risk Planning Risk Planning is developing and documenting organized, comprehensive, and interactive strategies and methods for identifying risks. It is also used for performing risk assessments to establish risk handling priorities, developing risk handling plans, monitoring the status of risk handling actions, determining and obtaining the resources to implement the risk management strategies. Risk planning is used in the development and implementation of required training and communicating risk information up and down the project stakeholder organization. Risk monitoring and control is the process of identifying and analyzing new risk, keeping track of these new risks and forming contingency plans incase they arise. It ensures that the resources that the company puts aside for a project is operating properly. Risk monitoring and control is important to a project because it helps ensure that the project stays on track.

To prioritize your risk management to do list, you need to determine which risks are most likely to occur, as well as which risks will result in the most severe harm. This exercise is called a risk assessment. For some organizations, losing power or water damage due to severe weather may be a frequent occurrence that has been successfully managed so that if it happens in the future there may be minimal disruption and financial impact; while for others, a catastrophic loss such as a child drowning, may be extremely unlikely given the supervision and safety procedures in place, but, because of the severity of the loss, risk management procedures at the waterfront/poolside are a high priority for that nonprofit.

25

(ii) The change request management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. It has two main goals: supporting the processing of changes which is mainly discussed here and enabling traceability of changes, which should be possible through proper execution of the process described here. There is considerable overlap and confusion between change management, change control and configuration control. The definition below does not yet integrate these areas. Change management is an important process, because it can deliver vast benefits (by improving the system and thereby satisfying "customer needs"), but also enormous problems (by ruining the system and/or mixing up the change administration). Furthermore, at least for the IT domain, more funds and work are put into system maintenance (which involves change management) than to the initial creation of a system. Typical investment by organizations during initial implementation of large ERP systems is 15-20% of overall budget. The field of manufacturing is nowadays also confronted with many changes due to increasing and worldwide competition, technological advances and demanding customers. Therefore, (efficient and effective) change management is also of great importance in this area. It is not unthinkable that the above statements are true for other domains as well, because usually, systems tend to change and evolve as they are used. Below, a generic change management process and its deliverables are discussed, followed by some examples of instances of this process. c) Write short notes on the following: (i) MS-Project (ii) Cost-benefit analysis Solution: (i) MS-Project MS Project is an application which the general MS Office users think to be another common Office application. However, it is very much different from the common Office applications and in some ways, it seems to do things on its own. MS Project is the most narrowly focus of all the Office applications. While the other Microsoft office programs tend to broad and general in their application, MS Project is designed exclusively to manage resource usage and project scheduling. MS Projects help to keep track of the progress of the tasks. It also helps to figure out how much each of the resources is doing on a project. MS Project is a tool to help you to plan projects, manage and update project information, and communicate the status once the project is under way. 26

The details of the project tasks and associated resources are entered into the system as a new project. The system will then display the data in such a way that the relationships of the tasks and their time scales can clearly be seen and potential problem areas identified. Project data can be entered and/or viewed in a number of ways; the three principal formats are charts, forms, and sheets. Charts can be either Gantt Charts or Network Diagram Charts both of which are a diagrammatic representation of the project data. You can combine any two single-pane views on the screen to create a combination view. In a combination view, the information in the bottom relates only to the task or resources in the top view. The reason for having combination views is to make the job of entering and analyzing information easier. At the heart of every project management system is a scheduling algorithm. An algorithm is a mathematical or logical equation that solves a complex problem by breaking down the problem into simple steps. When scheduling resources and parameters are entered into it, the scheduling algorithm produces a project schedule that would be impossible for you to produce manually. (ii) Cost Benefit Analysis A cost benefit analysis is done to determine how well, or how poorly, a planned action will turn out. Although a cost benefit analysis can be used for almost anything, it is most commonly done on financial questions. Since the cost benefit analysis relies on the addition of positive factors and the subtraction of negative ones to determine a net result, it is also known as running the numbers. A cost benefit analysis finds, quantifies, and adds all the positive factors. These are the benefits. Then it identifies, quantifies, and subtracts all the negatives, the costs CBA should be used for policies and projects, which unfold over time and be assessed by calculating a Net Present Value (NPV), or a Benefit-Cost Ratio (BCR). 4 informational inputs: 1. time horizon 2. benefit schedule 3. cost schedule 4. discount rate In any CBA, several stages must be conducted (Hanley and Spash, 1993): 1) Definition of the Project 2) Identification of the Project Impacts 3) Which Impacts are Economically Relevant? 4) Physical Quantification of Relevant Impacts 5) Monetary Valuation of Relevant Effects 6) Discounting of Cost and Benefit Flows 7) Applying the Net Present Value Test 8) Sensitivity Analysis Cost Benefit Analysis In 3 Easy Steps 1. Identify the cost - Cash is King

27

The first step in a cost benefit analysis is to establish a common measurement unit usually money. Sounds simple, but remember the time value of money a dollar in the hand today is worth much more than a dollar in the hand in a year's time. For most businesses, cash-flow is crucial, so if income is slow to appear, can you manage the outgoings in the meantime? Also, some costs or benefits are one-off or may be ongoing. 2. Cost Benefit Analysis Step 2 - Let's Talk Money The next step is to quantify the costs of doing the project and the resultant benefits. Costs often include; new equipment, specialist help, staffing, training, maintenance, lost business during implementation etc. 3. Identify the Benefit - It's Payback Time! The final stage is to calculate the "pay-back" time for the project. If the total costs are $40,000 and the ongoing benefits are $60,000 per year, the pay-back period could be calculated as $40,000/$60,000 = 8 months. If your business is going down fast, 8 months may be too long.

28