Qwertyuiopasdfghjklzxcvbnmqwe rtyuiopasdfg11111223444hjklzxc vbnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnmq Homework 1 wertyuiopasdfghjklzxcvbnmqwert MANAGING yuiopasdfghjklzxcvbnmqwertyuio SOFTWARE PROJECTS pasdfghjklzxcvbnmqwertyuiopas

dfghjklzxcvbnmqwertyuiopasdfgh [22-SEPT-2009] jklzxcvbnmqwertyuiopasdfghjklzx SUBMITTED TO:-……….. cvbnmqwertyuiopasdfghjklzxcvb nmqwertyuiopasdfghjklzxcvbnmq MS. KAMINI SUBMITTED BY:wertyuiopasdfghjklzxcvbnmqwert VIPLAV yuiopasdfghjklzxcvbnmqwertyuio ROLLNO:-RA3803A06 pasdfghjklzxcvbnmqwertyuiopas dfghjklzxcvbnmqwertyuiopasdfgh jklzxcvbnmqwertyuiopasdfghjklzx
112344434551 11111 | P a g e

Homework 1 Part A:Q1 :-> Illustrate the concept of Software projects Management? Why managing of software project is important?



Project management is a carefully planned and organized effort to accomplish a specific onetime objective. For example, construct a building or implement a major new computer system. Project management includes developing a project plan, which includes defining and confirming the project goals and objectives, identifying tasks and how goals will be achieved, quantifying the resources needed, and determining budgets and timelines for

completion. It also includes managing the implementation of the project plan, along with operating regular 'controls' to ensure that there is accurate and objective information on 'performance' relative to the plan, and the mechanisms to implement recovery actions where necessary. Projects usually follow major phases or stages including feasibility, definition, project planning, implementation, evaluation and support/maintenance. (Program planning is usually of a broader scope than project planning, but not always - note: the terms program and programmehave significant variations in their meaning in different geographical areas, e.g. Europe and USA.)

Q2:->Explain the series of steps of ISO 12207 Software development life cycle? ANS:

ISO 12207 is an ISO standard for software lifecycle processes. It aims to be 'the' standard that defines all the tasks required for developing and maintaining software.

The ISO 12207 standard establishes a process of lifecycle for software, including processes and activities applied during the acquisition and configuration of the services of the system. Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes. The standard is based on two basic principles: modularity and  Responsibility.  Modularity means processes with minimum coupling and maximum cohesion. Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.

Primary lifecycle processes:These processes are divided into five different main processes:

Acquisition covers the activities involved in initiating a project. The acquisition phase can be divided into different activities and deliverables that are completed chronologically.

Initiation: during this activity the following tasks are completed

The need is described why to acquire, develop, or enhance a product;

Supply:During the supply phase a project management plan is developed. This plan contains information about the project such as different milestones that need to be reached. This project management plan is needed during the next phase which is the development phase. 3.Development: During the development phase the software product is designed, created and tested and will result in a software product ready to be sold to the customer. Throughout time many people have developed means of developing a software application. The choice of developing method often depends on the present situation. The development method which is used in many projects is the V-model. Techniques that can be used during the development are UML for designing and TMap for testing. This entry contains the most important steps of the V-model.  Coding:

1.The code is created according to the high level design and the module design. 2. Execute Module test

Operation:The operation and maintenance phases occur simultaneously, the operation-phase consists of activities like assisting users in working with the created software product.

Maintenance:The maintenance-phase consists of maintenancetasks to keep the product up and running. The maintenance includes any general enhancements, changes and additions, which might be required by the end-users.

Deliverables:The different deliverables that are developed per activity are explained in this chapter.

High level design;

1.Module design: during this activity the following deliverables are developed: 2.Module design; 3. Coding: during this activity the following deliverables are developed:
 1.


Module test: during this activity the following deliverables are developed: 2.Module test report, this test report contains the test-results which are formed after a

module test of the application. Based on this test-report the project-team can decide which action to undertake further.

Integration test: during this activity the
following deliverables are developed:

1.Module test report, this test report contains the test-results which are formed after an integration test of the application. Based on this test-report the project-team can decide which action to undertake further.

System test: during this activity following deliverables are developed:



System test report;

The method presented in this entry can be used in a company that is responsible for creating and maintaining a software product for a customer. Especially when this company decides to build an application from scratch and that maintenance and assisting in the operation is also done by the company.

Q3:-> identify the objectives and problems which are going to be handled by the software projects? ANS:-THE MAIN OBJECTIVES:The starting point for any software project is to know what you’re actually trying to achieve. This post is going to look at how to go about collecting the objectives of a project.

The objective (or objectives) of a project are what you are trying to achieve by completing said project. They should not be confused with anything. Those are the deliverables of the project, not its objectives.

 

Stating the objectives:The objectives should be statements, preferably short, that encapsulate part, or all, of what you are trying to achieve with the project. They should be as concise and clearly stated as you can make them. Use the shortest words and the simplest language that you can. Then print them out and stick them somewhere visible. It is worth having the objectives somewhere prominent so that you can easily check whether what you are doing fits with the objectives.

An example might be that you’re building an automated software system for detecting stars and galaxies in astronomical data. Your objectives here could be: 1 – find the sky locations where there is likely to be a star or galaxy, given the data 2 – estimate the flux (brightness) of each source 3 – use the data to decide whether the source is a star or a galaxy It is worth spending time getting your objectives clear because if they are wrong or incomplete, then the impact will be enormous. A clear set of objectives will help you solve problems that occur later in the development process because it will allow you to check whether the problem, or its solution, fits with the objective. On the other hand, software with clear objectives is often a pleasure to read because the people writing the code understand what they’re aiming to achieve. Making your objectives clear from the beginning also helps reduces the chance they will need to be changed during the project because you will already have thought them through thoroughly. Even if the objectives do need to change, which does happen from time

to time as you start to implement your solution, clear objectives will allow you to spot this necessity rapidly and act before you go too far down the wrong path. When an objective must change, you should do two things. Firstly, don’t worry about it. Secondly, stop as soon as you realise the objectives have changed and work out the implications of the change. The objectives are more likely to change towards the beginning of the project as you work out the requirements and design (we’ll come to this later; one step at a time!) and when you begin implementing the solution. In conclusion, clear objectives are the basis of writing successful software. They are the compass by which the project is steered and, if we can continue the nautical analogy, will help you navigate the difficult waters of development.

Q4 :-> Outline the various activities to be performed at each level of step wise planning of projects?

ANS:- Three Stepwise phases for implementation ease From our initial meeting to project closure, Lawson Stepwise ensures execution is seamless, and nothing is overlooked. The StepWise method occurs throughout the following three phases define, establish, and execute, as illustrated in the table below:

1. Define phase During the Define (or Sales) phase, we invest the time it takes to develop a thorough understanding of your business needs and objectives. At the same time,we save time and simplify communication by capturing what we learn about your organization and your business in the following detailed materials:

Statement of Work

A document that defines roles, responsibilities,and the detailed scope of the project.

Project Plan and Budget

A specific time, budget and activity plan that takes into consideration input from the Statement of Work and your business priorities.

Learning Strategy and Plan

Ensures the learning strategy is discussed and agreed upon. StepWise initiates training near project onset to quickly get IT specialists and end users up to speed on the application. IT Solution Description Defines what the overall IT landscape and solution will look like when the project progresses. 2. Establish phase The Establish phase provides a rapid project kickoff based on Define phase activities, and involves team training and solution approval. Establish phase deliverables include:

Project Member Training
Know-how is key to success. Lawson has mapped out progressive courses that get you smart on your Lawson system fast. Designated IT specialists, project team members and end users can attend learning camps, workshops, and learning labs onor off-site.

Approved Solution
Your project team conducts an approved acceptance test to demonstrate that the solution has been configured to meet the Statement of Work. You approve the solution at the end of a successful test by signing off on the test.

3. Execute phase

New-solution execution is the ultimate objective. During the Execute phase, we test the final solution, train the entire organization, prepare for start-up, and close the project. Execute phase deliverables include:

System Test

Conducted by process owners and key users in a controlled IT environment with a full database, the system test is used to approve configured solution performance.

End-User Training

Run by your project team members or byLawson consultants. StepWise provides end-user training plans, job instructions, learning simulations, and course evaluations.

Full-Scale Test

Final test before go-live to ensure solution operates according to plan. End users perform the test in an operational IT environment using a full operational solution with each end user at their normal workplace.

Closing the Project
Formally conducted once completion criteria for each of the Execute phase deliverables is achieved.

Q5:-> illustrate the concept of feasibility study? Why it is important to go with this study?

ANS:- The feasibility study is an investigation

that results in a written document that: 1.Defines the scope of the problem. 2.Identifies the elements of the problem. 3.Identifies the evaluative criteria. Possible criteria include: the impact on the environment, safety and manufacturability; the political climate; the possible difficulties in the design phase; and appraisal of the return (profit) on investment. 4.Identifies possible alternative solutions. 5.Evaluate each solution with the criteria. The goal of the feasibility study is to discover possible solutions and to determine which of these appear to have promise and which are not feasible, and why. Each alternative is examined to determine whether or not it can be physically achieved, whether its potential usefulness is commensurate with the costs of making it available, and whether the return on the investment warrants its implementation. The feasibility study is in effect a pilot project whose primary purpose is to seek information

pertinent to all possible solutions to the problem. After the information has been collected and evaluated, and after the undesirable design possibilities have been discarded, the engineer still may have several alternatives to consider - all of which may be acceptable. During the generation of ideas, the engineer has intentionally avoided making any final selection in order to have an open mind for all possibilities and to give free rein to the thought processes. Now the number of ideas must be reduced to a few - those most likely to be successful, those that will compete for the final solution.

Software Feasibility Study


Software developers have learned that the traditional engineering feasibility study is not usually appropriate for software development. For example, software rarely has impact on the environment in the same manner as a chemical plant. Manufacturability is usually a non-issue. How much does it cost to copy a diskette? Therefore, software companies have developed their own variety of the feasibility study. Below is one based on Roger S. Pressman's book Software Engineering: A Practitioner's

Approach [fourth edition, McGraw-Hill, 1997, pages 253-259, in Bucknell's library on reserve for our course].

Part B
Q1 :-> How one can estimate the effort and activity risk for each activity used in step wise planning of projects? ANS:- Effort


Because software effort estimates are required when the requirements and design are still very immature, it is extremely important that more then one estimate be generated to establish the BOE. It is recommended that two to three different types of estimates be derived:

• •

A traditional engineering estimate typically based on a bottom-up decomposition, Model based estimate, and Analogical comparison to other similar tasks.

The engineering software estimate typically uses a straightforward methodology to derive effort, cost, and schedule. This includes analogy, engineering

buildup, or “Rules of Thumb.” Analogy compares the project at hand to “comparable” projects. The estimate then may be adjusted to account for any obvious differences (e.g., estimated size or complexity). Engineering buildup leverages expertise of people who have experience in software development. These experts apply their best judgment to estimate the duration and effort required to complete the project. The analysis may be broken down into work packages, modules, or activities to achieve greater granularity and accuracy. CERs, or “rules of thumb,” use simple factors such as productivity metrics, percentages, or multipliers that are easily applied to size, staffing, or other estimate data to derive cost, effort, and schedule. JPL and other Centers, e.g. JSC, track the size of development efforts and can derive a size estimate based on analogy to the historical data. Sizing by analogy, however, does not address all the relevant issues. What requires effort is the amount of code that needs to be written, modified and tested, not the amount of code that gets delivered. To estimate the development effort the number of Equivalent SLOC needs to be derived, which is based on weighting the cost of an inherited line relative to the cost of delivering a new line of code. Historically, there is a tendency to over estimate the amount of inheritance and to underestimate the cost of inheritance, so be conservative. The cost

models have algorithms built in to compute Equivalent SLOC. For a simplified approach to computing Equivalent SLOC apply the adjustment factors displayed in Exhibit 6 -11.

Software Heritage Effort Category Multiplier New design and new 1.2 code Similar design and new 1.0 code (nominal case) Similar design and some 0.8 code reuse Similar design and 0.6 extensive code reuse Exhibit 6 - 11: Effort Adjustment Multipliers for Software Heritage 14 Because no analogy is ever perfect and because expert judgment must be applied to obtain a best guess as to the SLOC to be developed it also important that estimation uncertainty be factored in. What is recommended is that the estimator estimate a size distribution based on the least or minimum number of time, the likely amount of time and the most amount of time for a development effort for each software function. These can then be combined using Monte Carlo techniques or by

computing the mean of the distribution. Most parametric cost models have this feature built-in. If you do not have access to Monte Carlo or statistical software, then an easy to compute heuristic is done with the use of Program Evaluation and Review Technique (PERT), which calculates the mean as Mean SW Range SW Developme Developmen nt Software Class t Productivit Productivity y (SLOC/WM) (SLOC/WM) Mission Critical 125 13-467 Flight SW Mission Support 184 80-262 Flight SW DSMS 197 148-347 Mission Critical 239 116-519 Ground SW Mission Support 295 103-607 Ground SW Development 157 129-207 Support Ground SW Exhibit 6-12: Software Development Productivity for JPL and NASA Average Projects (Equivalent Logical SLOC)

Finally to the development effort should be added all the additionally activities related to a development lifecycle such as the Software Management effort and maintenance (sustainment). This arrives at the total work effort (labor months).


Q2 :-> Discuss the concept of programme management? How these programmes are created and manage the allocation of resources within these programmes?


management or programme management is the process of managing
several related projects, often with the intention of improving an organization's performance. In practice and in its aims it is often closely related to Systems engineering. There are two different views of how programs differ from projects. On one view, projects deliver outputs; programs create outcomes.[1]. On this view, a project might deliver a new factory, hospital or IT system. By combining these projects with other deliverables and changes, their programs might deliver increased income from a new product, shorter waiting lists at the hospital or reduced operating costs due to improved technology. The other view[2] is that a program is nothing more than either a large project or a set (or portfolio) of projects. On this second view, the point of having a program is to exploit economies of scale and to reduce coordination costs and risks. The project manager's job is to ensure that their project succeeds. The programme manager, on the other hand, may not care about individual projects, but is concerned with the aggregate result or endstate. For example, in a financial institution a programme may include one project that is designed to take advantage of a rising market, and

another to protect against the downside of a falling market. These projects are opposites with respect to their success conditions, but they fit together in the same programme. According to the view that programs deliver outcomes but projects deliver outputs, program management is concerned with doing the right projects, whereas project management is about doing projects right. And also according to this view, successful projects deliver on time, to budget and to specification, whereas successful programmes deliver long term improvements to an organisation. Improvements are usually identified through benefits. An organization should select the group of programs that most take it towards its strategic aims whilst remaining within its capacity to deliver the changes. On the other hand, the view that programs are simply large projects or a set of projects allows that a program may need to deliver tangible benefits quickly. Consider the following set of projects: design of the new product - this delivers a design specification, modifications to the production line or factory delivers a manufacturing capability, marketing - delivers advertisements, brochures and pamphlets, staff training - delivers staff trained to sell and support the new product.

One view has it that these are different projects within a program. But in practice they can just as well be managed as sub-projects within a single project. Which approach to choose? Programme and project management are both practical disciplines, and the answer to such a question must be "whatever works." What works depends very much on the nature of the organization in which the project or program is run. Typically a program is broken down into projects that reflect the organization's structure. The design project will be run by the design team, the factory will manage the modifications to the production line, and so on. Organizational structure and organizational culture are key factors in how to structure a program. The distinction between the terms "outcome" and "output" is far from clear, except in a trivial sense. Each of the projects listed in the example above is designed to deliver some 'thing', known as a 'deliverable' or an 'output', and together they improve the organization. Where one draws the line between the complete single benefit that causes the improvement and its component parts is partly a matter of preference and partly a matter of the culture and structure of the organization. Either way, benefits will normally be enjoyed long after the end of the program and all of its component projects. The point is that to achieve maximum benefits, there must be an integration of parts into a whole. Whether this integration is managed in

something that is called a project or a programme is of secondary importance to understanding the benefits and managing the process of integration well. Many programs are concerned with delivering a capability to change. Only when that capability is transferred to the line management and utilised by the host organization will the benefits actually be delivered. On this view, a program team cannot, on their own, deliver benefits. Benefits can only be delivered through the utilisation of a new capability. Programs are normally designed to deliver the organization's strategy, such as an ambition to be the fourth biggest supermarket in a regio by 2015 or reduce wastage by 5% in two year's time. Program management also emphasises the coordinating and prioritizing of resources across projects, managing links between the projects and the overall costs and risks of the program. Program management may provide a layer above the management of projects and focuses on selecting the best group of projects, defining them in terms of their objectives and providing an environment where projects can be run successfully. Program managers should not micromanage, but should leave project management to the project managers.

Q3 :-> Discuss the various cost benefit evaluation techniques?
ANS:-Since many parts of the architecture
evaluation steps of the Cost Benefit Analysis Method (CBAM) depend on the stakeholders’ empirical knowledge and intuition, it is very important that such an architecture evaluation method be able to faithfully reflect the knowledge of the experts in determining Architectural Strategy (AS). However, because CBAM requires the stakeholders to make a consensus or vote for collecting data for decision making, it is difficult to accurately reflect the stakeholders’ knowledge in the process. In order to overcome this limitation of CBAM, we propose the two new CBAM-based methods for software architecture evaluation, which respectively adopt the Analytic Hierarchy Process (AHP) and the Analytic Network Process (ANP). Since AHP and ANP use pair-wise comparison they are suitable for a cost and benefit analysis technique since its purpose is not to calculate correct values of benefit and cost but to decide AS with highest return on investment. For that, we first define a generic process of CBAM and develop variations from the generic process by applying

AHP and ANP to obtain what we call the CBAM+AHP and CBAM+ANP methods. These new methods not only reflect the knowledge of experts more accurately but also reduce misjudgments. A case study comparison of CBAM and the two new methods is conducted using an industry software project. Because the cost benefit analysis process that we present is generic, new cost benefit analysis techniques with capabilities and characteristics different from the three methods we examine here can be derived by adopting various different constituent techniques.

Q4 :-> How the risk can be evaluated in managing the project programme?
ANS:-Risk is everywhere, so we cannot avoid it,
only manage to deal with it in the best possible manner. In software development, the most valuable projects are always the most risky. There are two general areas in which risk can be categorized. Some of the risks are known, either precisely or within a range of parameters. For example, the cost per day for each category of worker involved in the project is well-known. This type

of risk is not difficult to manage, and most managers have a great deal of experience handling them, so very little of the book deals with them. The second category are those risks that are largely unknown. These are items like the risk of mission critical software suffering a catastrophic failure to large, unexpected cost overruns. It is this category that is examined in detail in this book. Of course, the boundaries between these categories are extremely subjective and situation dependent. A small company with limited financial resources would consider a smaller cost overrun to be critical than a company more capable of taking a large financial risk. After the initial explanation that risk management is necessary, the next step is trying to quantify the risks. This involves charts of likelihood of delivery time that resemble normal distribution curves. Using such charts allows any prediction to include some natural wiggle room, which eliminates one of the most recurring and frustrating problems. Development managers are commonly asked to give a date for product delivery, and that date becomes fixed in stone. Upper echelons are notorious for hearing only the we can deliver on August first part of the message and ignoring the remaining, provided all the planets are in

alignment, there is no snow in January and no one takes a day off part of the message. Expressing the date in a diagram of this form means that it is impossible to see the date without also seeing the estimated range. The authors have also developed a risk assessment tool called RISKOLOGY, which can be freely downloaded from the companion web site. While the tool is not described in complete detail, there is enough background for you to be able to use it quickly. Chapter 13 deals with the core risks of software projects. The five risks listed are: * None of these risks is any surprise to experienced managers, although including them was necessary and the authors do a good job in explaining them. Chapter 14 puts forward a process for discovering risks, which is excellent and in the realm of how to learn what it is that you dont know. It is this approach that will separate those who succeed from those who must resort to faking success. The greatest and most dangerous risks are those never considered as possible events. Catastrophe brainstorming followed by scenario analysis is the strategy that the authors put forward. As a mathematician, I was pleased to see that the concept of probability is used to perform the risk analysis. Probability charts are used throughout the book to demonstrate the concepts and of course this more accurately describes our knowledge of

the future. Nothing in life is certain, so the probability limits need to be placed around every event. The software project without risk is so dull and uninteresting that no one with any talent would go near it. So, if you have talent, gear up by buying this book and plunge forward to take on the enormous challenges of making software that matters to the world.