Qwertyuiopasdfghjklzxcvbnmqwe

112344434551

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
11111 | P a g e

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

ANS:-SOFTWARE PROJECT
MANAGEMENT: -
 Project management is a carefully planned and
organized effort to accomplish a specific one-
time 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
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 maintenance-
tasks 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:

 Code;
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 the
following deliverables are developed:

2. System test report;

Example:-
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 kick-
off 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 on-
or 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 Engineering
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 Estimation:-
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).

ACTIVITY RISKS:-
 IDENTIFY AND QUANTIFY ACTIVITY
ACITIVITY BASED RISKS
 PLAN RISK REDUCTION AND
CONTINGENCY MEASURES WHERE
APPROPRIATE
 ADJUST OVERALL PLAN AND ESTIMATE
TO TAKE ACCOUNT OF RISKS

Q2 :-> Discuss the concept of

programme management? How
these programmes are created
and manage the allocation of
resources within these
programmes?
ANS:-Program
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 end-
state. 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.