Q.

1: As a programmer ,you are offered a promotion to project management but you feel
that you can make more effective contribution in technical rather than a managerial role.
Discuss whether you should accept the promotion

The right project management software is essential to the profitability of any professional
services organization. Maconomy offers project management capability that can be deployed
standalone or as part of an integrated solution

project management software

• Capture projects at bid stage to build an accurate revenue forecast by department

• Efficient project management of time and materials and fixed price projects and jobs with
comprehensive pricing capability

• Easy capture of project, contract and budget information reducing the risk of overruns

• Proactive alerts to let the project manager know when budgets are under pressure

• Strong time and expense registration, and effective resource management

• Seamless invoicing process improving working capital management and debtor days

• Easy consolidation of data rolling up to provide strong client management overview

Maconomy offers extremely strong project accounting combined with strong project
management. The project progress model provides project managers with a fully updated status
overview of each individual task. Strong financial control means that the project accounting
software is always correct. Maconomy is the ideal tool for to control project cost, and manage
the job costing process.

Project and budget creation is based on templates or actual data from previous projects. Budgets
can be broken down into convenient levels or phases using work breakdown structure on
multiple levels. You can get a full overview of pipeline, cash flow and peak periods by
dispersing budgets and sales estimates evenly across the entire lifetime of a project, and
employees are easily assigned to tasks on specific dates. Project accounting and work in progress
management is made simple using Maconomy.

Software cost estimation involves the determination of one or more of the following

estimates:
• effort (usually in person-months)

• project duration (in calendar time)

• cost (in dollars)

Most cost estimation models attempt to generate an effort estimate, which can then be

converted into the project duration and cost. Although effort and cost are closely related, they are

not necessarily related by a simple transformation function. Effort is often measured in

personmonths

of the programmers, analysts and project managers. This effort estimate can be converted

into a dollar cost figure by calculating an average salary per unit time of the staff involved, and
then multiplying this by the estimated effort required.

Requirement process Need for Software Requirement Specification (SRS) The Software
Requirement Specification describes what the proposed software should do without describing
how the software will do it.

1. It establishes the basis for agreement between the client and the supplier on what the software
product will do.

2. It provides a reference for validation of the final product

3. A high quality SRS is a pre-requisite for high quality product

4. A high quality SRS reduces the development cost as the cost of fixing a requirement error is
high as all the phases have to be repeated Requirement engineering tasks.

Q2: The process of project planning is iterative. and must be continually reviewed. Using
example explain the major reasons and the causes for this.
The waterfall model is a sequential software development process, in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation,
Analysis, Design, Construction, Testing and Maintenance.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.

Software development process

Activities and steps

1- Requirements · Specification

2- Architecture · Design

3- Implementation · Testing

4- Deployment · Maintenance

5- Methodologies

6- Agile · Cleanroom ·

7- Iterative · RAD · RUP · Spiral

8- Waterfall · Lean

GUI designer · Integrated development environment

The waterfall development model originates in the manufacturing and construction industries;
highly structured physical environments in which after-the-fact changes are prohibitively costly,
if not impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited as a 1970 article by Winston W.
Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model
as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is
generally used in writing about software development—to describe a critical view of a
commonly used software practice.

In Royce's original waterfall model, the following phases are followed in order:

1- Requirements specification

2- Design
 3- Construction

4- Integration

5- Testing and debugging

6- Installation

7- Maintenance

The waterfall model proceeds from one phase to the next in a sequential manner. For example,
one first completes requirements specification, which after sign-off are considered "set in stone."
When requirements are completed, one proceeds to design. The software in question is designed
and a blueprint is drawn for implementers (coders) to follow—this design should be a plan for
implementing the requirements given. When the design is complete, an implementation of that
design is made by coders. Towards the later stages of this implementation phase, separate
software components produced are combined to introduce new functionality and reduced risk
through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is completed and perfected. However, there are various modified waterfall
models (including Royce's final model) that may include slight or major variations upon this
process.
Modified models

In response to the perceived problems with the pure waterfall model, many modified waterfall
models have been introduced. These models may address some or all of the criticisms of the pure
waterfall model.[citation needed] Many different models are covered by Steve McConnell in the
"lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.

While all software development models bear some similarity to the waterfall model, as all
software development models incorporate at least some phases similar to those used in the
waterfall model, this section deals with those closest to the waterfall model. For models that
apply further differences to the waterfall model, or for radically different models seek general
information on the software development process.
 Q.4: Decisions made by senior management can have a significant impact on the
effectiveness of a software engineering team. Provide five examples to illustrate this.

Googling the expression "problems with software development” results in more or less the
following items: requirement complexity, customers' inability to know all the requirements in
advance, changes in requirements, difficulties in managing frequent changes, process
bureaucracy, difficulties in estimating development times, budget overrun, and the application of
a wrong process for the development process.

A fast glance is sufficient to reveal that all these problems are connected to people (mainly
customers and team members) and that their origin is rooted in human aspects (primarily
cognitive and social) rather than in technological ones. The outcomes of these problems are well
known. Such outcomes include, for example, buggy software products and customers who are
unsatisfied with the products they receive (some estimations indicate that about 75% of
customers are not pleased with the product they requested). The first outcome mentioned clearly
derives from a cognitive factor: testing software products is not an easy or trivial task; the second
outcome derives from a social issue, namely the communication channels between customer and
developers.

This perspective, which emphasizes the importance of the human aspect in software
development processes, is further supported by a study of "the Best and Worst iClass" projects
conducted by Quantitative Software Management. The report, published on August 1, 2005 by
Application Development Trends, is based on a survey of 536 IT projects developed in 31
companies in 16 countries, ranging in subject from aerospace to financial IT, and using 179
programming languages. It was found that, the best-in-class software development projects are
shipped to market 3.37 times faster, and are 7.48 times cheaper, than the worst projects. The
relevant point for our discussion is that people, not tools, influence these differences most
significantly. Specifically, four factors contributed to the above-mentioned results, and only one
was technology-related. The rest concerned management and technology approaches.
Specifically, development teams in the “best” category were able to control changes in
requirements, used tools effectively, and had better project leadership. Technological factors –
tools – ranked only third as a factor influencing the quality of the projects.

. The main reason for this is, in my opinion, that software is a unique intangible entity with
which the human mind has not been shaped to cope during its evolution; therefore, our ability to
deal with such intangible artifacts is limited. It can be rightly argued that many intangible entities
have been dealt with during human evolution – dreams, fears, stories, plans, and so on. This, of
course, is true. The difference, however, between software and such entities is expressed mainly
in two features. First, these entities are not products developed by someone for the use of
someone else. Second, software is not only an intangible product, it is also executed on a
computer. This means that the developed artifact is not the one that is actually used by its users.
The same argument that highlights software uniqueness is very well applicable also with respect
to other artifacts, such as knowledge and the emerging discipline of knowledge management.
Still, although knowledge management deals with an intangible entity – knowledge – it is not a
product that is constructed by someone for the use of someone else. As it turns out, and as is
explained in what follows, software intangibility influences almost every activity conducted in
the course of software development. For purposes of clarity, the term software will, hereinafter,
mean the code itself and not the product (the software tool or the application) generated by the
code.

First, the fact that software is an intangible entity increases the need for verbal communication
between teammates and between customers and developers. When wishing to communicate an
idea, it is not longer sufficient to point at something and form an impression based on sight; it is
no longer possible to touch it and make sens of its nature; it is not possible to hear the sounds it
makes and understand what this sound means. In general, our ability to use our senses for
software-related communication is limited; therefore, the importance of verbal communication
between teammates and between teammates and customers is increased. If such communication
is so vital, then it is not surprising that if it goes wrong, problems emerge.

Second, when a team works on an intangible entity it is harder to build a relationship of trust.
The reason for this is that under the common belief that knowledge is power, with both its
positive and negative aspects, it is easier to hide knowledge when the subject being dealt with is
an intangible entity (simply because it is easier to hide the fact that knowledge is not being
shared). This lack of trust has a back-influence on the communication between people, which, as
explained in the previous paragraph, has an important impact on the successful performance of
the software development task.

So far, we have seen how software intangibility influences mainly the social aspect of software
development. In the next paragraphs I will highlight the way in which the fact that an intangible
entity – software – is executed on a computer further influences the entire process of software
development, this time mainly from a cognitive perspective.

First, the facts that software is an in tangible entity and is executed on a computer enable us to
create complex structures, made up of loops and branches. To understand the contribution of this
ability to the discussion conducted here, it is sufficient to imagine what would happen to a
physical infrastructure if we allowed such complexity in the creation of tangible products.
Furthermore, this ability also creates a situation in which it is hard to predict the outcome when
change is introduced. Second, as mentioned before, the execution of software on a computer
creates a situation in which the product is not the outcome of its inputs. That is, if in the case of a
tangible product, the material of the product is the outcome of the processing of the inputs (i.e.
raw materials) used for its production, in the case of software products we obtain a product that
is made up of a different kind of building blocks. Third, the fact that software has a relatively
complex structure and the fact that the product is of a different kind than its building blocks,
increase the cognitive complexity related to software testing. Fourth, and directly derived from
the first three points, the development process is not linear in terms of development time. That is,
whereas it is possible to develop 80% of the specifications in 20% of the development time, there
are cases in which the duration of the final 5% of the entire software development is not
proportionally to its estimation. As a result, it is very hard to estimate both the development time
and development pace and to take decisions accordingly. In his book The Mythical Man-Month
(1975, 1995) Brooks has a lot to add about this idea. Traditional software development processes
are inspired by production lines of traditional manufacturing processes, in which each step has an
input received from the previous step, and an output delivered to the next step. The above
analysis of software development processes conveys the idea that because software is an
intangible product that is executed on a computer, its development process should be carried out
according to a different paradigm. One possible alternative software development paradigm
consists of the idea that the different activities conducted during a typical software development
process are revisited several times during the development process. This concept is the basis for
agile software development. For example, with respect to software design, it is well known at in
many cases the design is not at all identical to the code that should reflect it. This is because
software development is an on-going learning process, in which both developers and customers
continuously improve their understanding of the developed product. Accordingly, software
development processes should support such a learning process. Specifically, in the case of
software design, such a development process will enable to check, at different time points,
whether gaps exist between the intended design and the actual design, to understand the source
of such gaps (if found) and, based on this understanding, to adjust the code or the design. In
future columns I will continue to explore the activity of software development from different
angles, addressing mainly social and cognitive perspectives. Specifically, in the next column, I
will expand this idea with respect to software testing.

Q 3 Software project complexity influences the estimation accuracy. Develop a list of

software characteristics that effect the complexity of a project. Prioritize the list

Just as we typically need to determine the weight, volume, and dynamic flight characteristics of a
developmental aircraft as part of the planning process, you need to determine how much
software to build. One of the main reasons software programs fail is our inability to accurately
estimate software size. Because we almost always estimate size too low, we do not adequately
fund or allow enough time for development. Poor size estimates are usually at the heart of cost
and schedule overruns.
The key to credible software sizing is to use a variety of software sizing techniques, and not to
rely on a single source or method for the estimate. Reliance on a single source or technique
represents a major contribution to program cost and schedule risk, especially if it is based
exclusively on a contractor’s bid. There are two common types of size inaccuracies for which
you can compensate to some degree.

1. Normal statistical inaccuracies can be dealt with by using multiple data sources and estimating
methodologies, or by using multiple organizations to do the estimating and check and analyze
results.

2. The earlier the estimate is made — the less is known about the software to be developed —
and the greater the estimating errors.

Basing your estimates on more than one source is sound advice for both types of discrepancies.
Because accuracy can be improved if estimates are performed with smaller product elements,
base your estimates on the smallest possible unit of each component.

Software size has a direct effect on overall development cost and schedule. Early significant
deviations in software size data indicate problems such as:

1- Problems in the model(s), logic, and rationale used to develop the estimates,

2- Problems in requirements stability, design, coding, and process,

3- Unrealistic interpretation of original requirements and resource estimates to develop the

system,

4- Faulty software productivity rate estimates.

Significant departures from code development estimates should trigger a risk assessment of the
present and overall effort. Size-based models should be revisited to compare your development
program with those of similar domain, scope, size, and complexity, if possible.

The software product line strategy is a comprehensive approach that touches many facets of an
organization. Software product line initiation, even “green field” initiatives, typically occurs in
an existing corporate environment. Corporate or business unit initiatives set goals and often
mandate strategies to achieve those goals. The software product line effort must be consistent
with these previously established strategies. Product production strategies are guidelines that
define how the organization will manage the actual creation of a product [Chastek 02]. Aspects
of the software product line strategy will, almost certainly, provide guidance on some of the
same issues as the more general product production strategy. For example, a software
development business unit can find itself constrained by the initiatives of the hard goods units of
the corporation. These units have often been in existence longer or manufacture a more tangible
portion of each product. In the remainder of this paper we will focus on the integration of a
software product line strategy and product production strategies. There are many widely
recognized corporate strategies for product production or product manufacture such as Product
And Cycle-time Excellence (PACE) [McGrath 96], Six Sigma [Pande 00], and Supply Chain
Management [Chopra 00]. Each strategy solves specific types of problems and imposes
assumptions that constrain possible solutions. The scope of each strategy varies. Supply chain
management impacts most of the phases in a manufacturing process but it is limited to the
management of inputs into these phases and delivery to customers. Six Sigma techniques impact
the record keeping and decision making of most steps in the product development process but
not the technical details of how to carry out the steps. The PACE strategy is a comprehensive
strategy that specifies some portion of the organizational structure and establishes priorities
among activities in the manufacturing process. These examples illustrate how the software
product line and product production strategies can have one of four relationships with one
another. The product line strategy (PL) may overlap with another strategy (S), there is some
region of potential conflict or agreement. There are also regions in which neither interacts with
the other. The two strategies must be synchronized in the common region and each must be
modified to accommodate the compromises necessary in the region of commonality. Strategy S
may totally encompass strategy PL, Figure 1b. Strategy S will often dominate strategy PL by
defining organizational and management structures. Strategy PL must be integrated into strategy
S. This situation has the potential to reduce the effectiveness of the PL strategy.

Q.5; Some very large software projects involve writing millions of lines of code .Suggest
how useful the cost estimation models are likely to be fo such systems. Why might be the
assumptions on which they are based be invalid for very large software systems

Cost estimation models are mathematical algorithms or parametric equations used to estimate the
costs of a product or project. The results of the models are typically necessary to obtain approval
to proceed, and are factored into business plans, budgets, and other financial planning and
tracking mechanisms.

These algorithms were originally performed manually but now are almost universally
computerized. They may be standardized (available in published texts or purchased
commercially) or proprietary, depending on the type of business, product, or project in question.
Simple models may use standard spreadsheet products.

Models typically function through the input of parameters that describe the attributes of the
product or project in question, and possibly physical resource requirements. The model then
provides as output various resources requirements in cost and time.

Cost modeling practitioners often have the titles of cost estimators, cost engineers, or parametric
analysts
COCOMO (Constructive Cost Model) is a model that allows software project managers to
estimate project cost and duration. It was developed initially (COCOMO 81) by Barry Boehm in
the early eighties The COCOMO IImodel is a COCOMO 81 update to address software
development practices in the 1990's and 2000's. The model is by now invigorative software
engineering artifact that has, from customer perspective, the following features:

• The model is simple and well tested

• Provides about 20% cost and 70% time estimate accuracy

In general, COCOMO II estimates project cost, derived directly from person-months effort, by
assuming the cost is basically dependent on total physical size of all project files, expressed in
thousands single lines of code (KSLOC). The estimation formulas have the form:

Effort (in person-months) = a x KSLOCb

where coefficient a is about 3 (2.94), and scaling factor b is close to 1 (1.0997).

There are similar COCOMO formulas for project duration (expressed in months) and average
size of project team. Interestingly, project duration in COCOMO is approximately cube root of
effort (in person-months).

In practice, COCOMO parameters can be greatly different from its typical values. COCOMO II
provides classification of factors that can have an influence on project cost, and lets you make
better approximation of coefficients and scaling factors for your particular project. As the result
of adjustment, a coefficient value falls between 0.056 120. for COCOMO II list of adjustment
factors that affect first parameter. Model-driven adjustment of scaling factor b is new in
COCOMO II model and reflects latest trends in software engineering. You can see scaling
factors descriptions

Many project managers used to negotiate project costs with trade-off triangle and trade-off
matrix in terms of product functionality, quality, and schedule. If this is a case for you, you
might be intrigued how COCOMO II adjustment parameters fit into this picture. The answer is
that COCOMO II parameters can be viewed as two sets of parameters. The first set is external
and can be loosely matched to trade-off triangle/matrix view and its vocabulary is frequently
used while negotiating costs with stakeholder, and the second set is COCOMO II internal and
usually cannot be used for this purpose. In this trade-off triangle/matrix perspective, schedule is
loosely corresponding to SCED (required development schedule), quality to RELY (required
reliability), and functionality to a combination of CPLX (product complexity), DATA (database
size), TIME (execution time), DOCU (documentation match to life-cycle needs), and
occasionally RUSE, STOR, PVOL parameters. COCOMO II internal parameters such as
parameters for evaluation of personnel capabilities/experiences, used project tools and others are
obviously important for project cost estimates, but usually are not a subject of cost
communications with stakeholder.

There are well-approbated COCOMO II tools on the market that calculate these parameters for
you, asking questions about particular project in natural language, such as How experienced is
the development team? or How tough is the project schedule?and, thus, hiding model details in
the background.

COCOMO II supercedes earlier version of COCOMO such as COCOMO 81, Ada COCOMO,
which are considered by now as outdated. The model simplifies inception phase cost estimates
by reducing the total number of parameters to seven (from 15 in the original COCOMO model),
and suggests to use functional points for inception phase, and SLOC for later, more accurate
phases. In fact, COCOMO II reduces controversy of what project metrics to use SLOC or
functional points making the new model more flexible.

Comparing to classical COCOMO 81, COCOMO II introduces five scale factors, at least three of
them are directly related to PM activities, and, thus, raises the role of project management in
reducing project costs:

• Takes into account process maturity in the organization (CMM levels)

• Takes into account the degree to which project architecture exists and is stabilized before
construction phase

• Takes into account relationships perspective: team cohesion, relations with stockholder

If you have project source code, and some project details, this is all you need to make a simple
cost estimate. Surely, you dont have a source code before starting your project, and this approach
is more like post-mortem analysis OK, this is my intention! By doing so, some chronological
accuracy will be lost, but real cost estimate will be more correct.

Q. 6 Cost estimates are inherently are risky irrespective of the estimation techniques used.
Suggest four ways in which the risk in a cost estimate can be reduced .

Estimation involves answering the following questions:

1. How much effort is required to complete each activity?

2. How much calendar time is needed to complete each activity?

3. What is the total cost of each activity?

Project cost estimation and project scheduling are normally carried out together. The costs of
development are primarily the costs of the effort involved, so the effort computation is used in
both the cost and the schedule estimate. However, you may have to do some cost estimation
before detailed schedules are drawn up. These initial estimates may be used to establish a budget
for the project or to set a price for the software for a customer.

There are three parameters involved in computing the total cost of a software development
project:

• Hardware and software costs including maintenance

• Travel and training costs

• Effort costs (the costs of paying software engineers).

For most projects, the dominant cost is the effort cost. Computers that are powerful enough for
software development are relatively cheap. Although extensive travel costs may be needed when
a project is developed at different sites, the travel costs are usually a small fraction of the effort
costs. Furthermore, using electronic communications systems such as e-mail, shared web sites
and videoconferencing can significantly reduce the travel required. Electronic conferencing also
means that travelling time is reduced and time can be used more productively in software
development. In one project where I worked, making every other meeting a videoconference
rather than a faceto- face meeting reduced travel costs and time by almost 50%. Effort costs are
not just the salaries of the software engineers who are involved in the project. Organizations
compute effort costs in terms of overhead costs where they take the total cost of running the
organization and divide this by the number of productive staff. Therefore, the following costs are
all part of the total effort cost:

1- Costs of providing, heating and lighting office space

2- Costs of support staff such as accountants, administrators, system managers, cleaners and
technicians

3- Costs of networking and communications

4. Costs of central facilities such as a library or recreational facilities

5. Costs of Social Security and employee benefits such as pensions and health Insurance.

This overhead factor is usually at least twice the software engineer’s salary, depending on the
size of the organization and its associated overheads. Therefore, if a company pays a software
engineer $90,000 per year, its total costs are at least $180,00 per year or $15,000 per month.
Once a project is underway, project managers should regularly update their cost and schedule
estimates. This helps with the planning process and the effective use of resources. If actual
expenditure is significantly greater than the estimates, then the project manager must take some
action. This may involve applying for additional resources for the project or modifying the work
to be done. Software costing should be carried out objectively with the aim of accurately
prediction the cost of developing the software. If the project cost has been computed as part of a
project bid to a customer, a decision then has to be made about the price quoted to the customer.
Classically, price is simply cost plus profit. However, the relationship between the project cost
and the price to the customer is not usually so simple. Software pricing must take into account
broader organizational, economic, political and business considerations. Therefore there may not
be a simple relationship between the price to the customer for the software and the development
costs. Because of the organizational considerations involved, project pricing should involve
senior management (i.e., those who can make strategic decisions), as well as software project
managers.

For example, say a small oil services software company employs 10 engineers at the beginning
of a year, but only has contracts in place that require 5 members of the development staff.
However, it is Bidding for a very large contract with a major oil company that requires 30 person
years of effort over 2 years. The project will not start up for at least 12 months but, if granted, it
will transform the finances of the small company. The oil services company gets an opportunity
to bid on a project that requires 6 people and has to be completed in 10 months. The costs
(including overheads of this project) are estimated at $1.2 million. However, to improve its
competitive position, the oil services company bids a price to the customer of $0.8 million. This
means that, although it loses money on this contract, it can retain specialist staff for more
profitable future projects.