ASSIGNMENT

ON
SOFTWARE PROJECT
MANAGEMENT

Submitted To: Submitted By:

Ms. PENCY NEEL KAMAL
Roll no - RS1906B31
Reg no - 10901526
Q.1 . “Before the project can begin, the manager and the software team must estimate
the work to be done, the resources that will be required, and the time that will elapse
from start to finish.”

SOFTWARE ESTIMATION:

SOFTWARE ESTIMATION SCOPE CONSIDERATION Functions described in the “Statement

of Scope” or within the Use-Cases are evaluated and in some cases refined to provide more detail
point to the beginning of Estimation. Because both Cost and Schedule Estimates are functionally
oriented, some degree of functional decomposition is useful. Performance considerations
encompass Processing and Response Time requirements. Constraints identify limits placed on
the software by hardware, available memory size on other existing system.

SOFTWARE ESTIMATION:

SOFTWARE ESTIMATION SCOPE CONSIDERATION Once the Project Scope has been
identified it is reasonable to ask yourself:- - Can we build the Software to meet this scope? - Is
the Project feasible? Often Software Engineers rush past these questions only to become mired
(become stuck) in a Project that is doomed from the onset. Since not everything in real life is
feasible, the Software Feasibility is emphasized in Estimation. Software Feasibility has four solid
dimensions: - Technology - Finance - Time - Resources

SOFTWARE ESTIMATION:

SOFTWARE ESTIMATION SOFTWARE SCOPE AND FEASIBILITY Once the Software

Scope and Feasibility have been identified the second task is Estimation of the “RESOURCES”
required to accomplish the Software Development Effort. RESOURCES The three major
categories of Software Engineering Resources: - People - Reusable software components. -
Development environment (H/W, S/W Tools) Each Resources is specified with four
Characteristics: - Description of the resource. - A statement of availability. - Time when
resources will be required. - Duration of the time that resource will be applied. NOTE: The last
two characteristics can be viewed as a “Time Window”. Availability of the Resource for a
specified window must be established at the earliest practical time.
The final process in developing your project plan is to develop the project schedule - the
sequencing of the tasks and the allocation of team members and stakeholders to those tasks.

In planning our journey we often tend to plan the schedule for our journey before we've sorted
out the estimates, costs, availability of flights and risks. As a result, once we've contacted the
airlines, we have to re-plan our entire journey because of costs and schedules.

In planning projects, the scheduling of tasks is the last process of planning. However, as we'll
cover later in this Chapter, once we have developed our schedule, we may need to re-schedule
certain tasks or people to shorten the schedule or to more efficiently allocate team members
across the tasks.

In developing the project schedule, there are three basic steps. The first is to develop the network
or relationships between the tasks; the second step is to allocate the people and adjust the
estimates for duration (remember that we made our estimates in effort in the previous chapter)
and the final process is to adjust the schedule for efficient allocation of resources.

However, before we get into developing the schedule, we need to look at some basic concepts
behind the scheduling process.

Task Dependencies and Relationships

The key to scheduling is to determine which tasks require something from other tasks before they
can start. That is, you must identify the dependencies between your tasks. For example, in
planning our journey, until you've booked your flights you cannot confirm your hotel bookings.

There are two major types of dependency. The first is one task requires the output from another -
a delivery or output dependency. In Mary's project, she needs to evaluate the various education
vendors and produce a Vendor Report before she and the team can commence the pilot education
programme. Alternatively, a task may require a person to finish a task so that they start another
task - a resource dependency. Once, Mary has finished producing the Vendor Report, she can
begin designing the training programme.

There are different types of relationships between tasks as well. The most common relationship
is called a finish-to-start relationship. In this relationship between tasks, one task must finish
before the dependent task can start. This relationship is often associated with output
dependencies. However, sometimes it is possible to overlap tasks. For example, once Mary has
started analysing her current procedures, she can also begin to document the problems of the
current statistics processing. This relationship is called a start-to-start. With start-to-task
relationships you must identify how long after the first task has started the second task can start.
The large and growing body of software development organizations implement process
methodologies. Many of them are in the defense industry, which in the U.S. requires a rating
based on 'process models' to obtain contracts.

The international standard for describing the method of selecting, implementing and monitoring
the life cycle for software is ISO 12207.

A decades-long goal has been to find repeatable, predictable processes that improve productivity
and quality. Some try to systematize or formalize the seemingly unruly task of writing software.
Others apply project management techniques to writing software. Without project management,
software projects can easily be delivered late or over budget. With large numbers of software
projects not meeting their expectations in terms of functionality, cost, or delivery schedule,
effective project management appears to be lacking.

Organizations may create a Software Engineering Process Group (SEPG), which is the focal
point for process improvement. Composed of line practitioners who have varied skills, the group
is at the center of the collaborative effort of everyone in the organization who is involved with
software engineering process improvement.
Q 2. “Software cost and effort estimation will never be an exact science. Too many
variables— human, technical, environmental, political—can affect the ultimate cost of
software and effort applied to develop it.” Do you support this statement. Justify your
answer with a suitable example

In the last decade or so, many software cost estimation models have been developed. These differ
substantially from each other, particularly with respect to the inputs required and their outputs. For a
software manager, the problem of selecting a particular model, or a combination of models that can be
applied to an individual organization, is not all trivial. This paper describes our efforts to solve this
problem for two organizations who had collected data on past development efforts. Statistical correlations
between the actual and the estimated efforts calculated by using different cost estimation models were
obtained. Regression analysis revealed that the cost model that is used by the organizations is not ideal for
their environment. Statistical tests show that the results obtained are indeed statistically significant. The
methodology used to perform the case study is applied to predict the development effort for a project, and
the result is quite impressive.

Software Estimation
Software measurements, just like any other measurement in the physical world, can be
categorized into Direct measures and Indirect measures. Direct measures of the software process
include measurement of cost and effort applied. Direct measures of a product include Lines Of
Code (LOC) produced, execution speed, memory size, and defects reported over some set of time.
Indirect measures of the software process include measurement of resulting features of the
software. Indirect measures of the product include its functionality, quality, complexity,
efficiency, reliability, maintainability etc.

In the starting era of computers, software cost was a small proportion of the cost for complete
computer based system. An error in estimation of software didn't have a major impact. But, today
software is the most expensive element in many computer-based systems. Large cost estimation
errors can make the difference between profit and loss. Cost overruns can be disastrous for the
developer.

Estimation is not an exact science. Too many variables - human, technical, environmental, and
political - can affect the ultimate cost of software and effort applied to develop it.
In order to make a reliable cost and effort estimation there are lot of techniques that provide
estimates with acceptable amount of risk.

These methods can be categorized into Decomposition techniques and Empirical Estimation
models. According to Decomposition techniques the software project is broken into major
functions and software engineering activities (like testing, coding etc.) and then the cost and
effort estimation of each component can be achieved in a stepwise manner.

Finally the consolidated estimate is the clubbed up entities resulting from all the individual
components. Two methods under this head are Lines of Code (LOC) and Function Points (FP)
Estimation. Further Empirical Estimation models are used to offer a valuable estimation
approach, which is based on historical data (experience).
Q.3 A software house got a software project to develop a software for autopilot. Which
SDLC is suitable for this project? Explain that model in detail. And what are the
drawbacks of that model

Planning

The important task in creating a software product is extracting the requirements or requirements
analysis. Customers typically have an abstract idea of what they want as an end result, but not
what software should do. Incomplete, ambiguous, or even contradictory requirements are
recognized by skilled and experienced software engineers at this point. Frequently demonstrating
live code may help reduce the risk that the requirements are incorrect.

Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.

Certain functionality may be out of scope of the project as a function of cost or as a result of
unclear requirements at the start of development. If the development is done externally, this
document can be considered a legal document so that if there are ever disputes, any ambiguity of
what was promised to the client can be clarified.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for
the project.

Software testing is an integral and important part of the software development process. This part
of the process ensures that defects are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing of an API, be it
external or internal. It is very important to document everything in the project.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or
otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to realize that. It would
not matter how much time and planning a development team puts into creating software if
nobody in an organization ends up using it. People are often resistant to change and avoid
venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to
have training classes for new clients of your software.

Maintaining and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. It may be
necessary to add code that does not fit the original design to correct an unforeseen problem or it
may be that a customer is requesting more functionality and code can be added to accommodate
their requests. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor
cost, then it is likely that the overall quality of at least one prior phase is poor.[citation needed] In that
case, management should consider the option of rebuilding the system (or portions) before
maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development
teams to interface with customer/field teams testing the software to identify any real or perceived
issues. These software tools, both open source and commercially licensed, provide a
customizable process to acquire, review, acknowledge, and respond to reported issues. (Software
maintenance)

Software Development Models

Several models exist to streamline the development process. Each one has its pros and cons, and
it's up to the development team to adopt the most appropriate one for the project. Sometimes a
combination of the models may be more suitable.

Waterfall Model

, but provided emphasis in a key area many felt had been neglected by other methodologies:
deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The Spiral is visualized as a process passing through some number of iterations, with the four
quadrant diagram representative of the following activities:

1. formulate plans to: identify software targets, selected to implement the program, clarify
the project development restrictions;
2. Risk analysis: an analytical assessment of selected programs, to consider how to identify
and eliminate risk;
3. the implementation of the project: the implementation of software development and
verification;

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to
support software reuse, software quality can help as a special goal of integration into the product
development. However, the spiral model has some restrictive conditions, as follows:

1. spiral model emphasize risk analysis, but require customers to accept and believe that
much of this analysis, and make the relevant response is not easy, therefore, this model is
often adapted to large-scale internal software development.
 2. If the implementation of risk analysis will greatly affect the profits of the project, then
risk analysis is meaningless, therefore, spiral model is only suitable for large-scale
software projects.
3. Good software developers should look for possible risks, an accurate analysis of risk,
otherwise it will lead to greater risk.

First stage is to determine the stage of the goal of accomplishing these objectives, options and
constraints, and then from the perspective of risk analysis program, development strategy, and
strive to remove all potential risks, and sometimes necessary to achieve through the construction
of the prototype. If some risk cannot be ruled out, the program to end immediately, or else start
the development of the next steps. Finally, evaluation results of the stage, and the design of the
next phase.

Iterative and Incremental development

Iterative development prescribes the construction of initially small but ever larger portions of a
software project to help all those involved to uncover important issues early before problems or
faulty assumptions can lead to disaster. Iterative processes are preferred[y commercial developers
because it allows a potential of reaching the design goals of a customer who does not know how
to define what they want.

Agile development

Agile software development uses iterative development as a basis but advocates a lighter and
more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather
than planning, as their primary control mechanism. The feedback is driven by regular tests and
releases of the evolving software.

There are many variations of agile processes:

• In Extreme Programming (XP), the phases are carried out in extremely small (or
"continuous") steps compared to the older, "batch" processes. The (intentionally
incomplete) first pass through the steps might take a day or a week, rather than the
months or years of each complete step in the Waterfall model. First, one writes automated
tests, to provide concrete goals for development. Next is coding (by a pair of
programmers), which is complete when all the tests pass, and the programmers can't think
of any more tests that are needed. Design and architecture emerge out of refactoring, and
come after coding. Design is done by the same people who do the coding. (Only the last
feature — merging design and code — is common to all the other agile processes.) The
incomplete but functional system is deployed or demonstrated for (some subset of) the
users (at least one of which is on the development team). At this point, the practitioners
start again on writing tests for the next most important part of the system.
Q.4 Identify the factors affecting the size of the task and work rate for the following
activities :
(A) installing computer workstation in new office;
(b) transporting assembled PC from the factory where they were assembled to
warehouse distributed in different part of the country;
(c)typing in and checking the correctness of data that is populating a new
database.
(d) system testing a newly written software application

(A) Installing computer workstation in new office

Installing office and Installing computer workstation in new office such as computer workstation
desks, office chairs, filing cabinets and more is a big business. All companies from the largest
Fortune 500s to the smallest one-man offices need to set up desks and office chairs for their
employees.Considering all the planning and labor that goes in to the set up of a new office —
from designing the layout to selecting the individual pieces to actually installing the office
furniture — its no wonder that new office build-outs are such a booming business.

The first step in the set up of a new office is to design the layout you would like for your new
office. While giving every employee a private office would be nice, a more efficient use of
expensive office space is to give top-ranking CEOs their private corner office, and provide the
rest of your employees with computer workstation desks.

While considering the layout, remember to think about all aspects of your business. Do you need
a grand computer workstation desk for several receptionists, or will a small desk and office chair
suffice? How many conference rooms and private offices do you need? How will customers and
employees flow through the space? Do you need areas for printers and copy machines? Don’t
forget about a break room or kitchen. Computer layout for your employees is an important factor
in choosing the right computer workstation desk; will your employees use large desktop setups
with multiple screens, or would smaller desks with laptop hookups be more appropriate? And
ignoring ADA compliance or fire codes regarding square feet per employee can land you in hot
water, or at least force you to start the entire process over again.

After completing the planning and layout stages of your new office and workstation build-out,
the next step is to buy the computer workstations that will make up the majority of your office.
Buying computer workstations can be as simple as looking for computer desks for sale and then
arranging for shipping of the workstation desks. Or there are numerous companies that you can
hire to handle the planning and installing of computer workstations for your office from start to
finish.
When buying computer workstations, make sure you have the exact measurements you need
handy. This will be important as computer workstation desks come in all shapes and sizes
imaginable, and more important than the look of your desks is that they fit into the space allotted.
You will also want to know many of the features available in the vast market of computer desks
for sale, so that you know what is available and which features you want most

(d) system testing a newly written software application

The present report documents the testing of the Cyclades Deliverables D3.1.1 - D3.7.1, i. e. the
Working Prototypes of the Cyclades services, and the testing of Deliverable D4.1.1, the Open
Archives Working Service Environment which consists of the integration of the service
components into one environment.
The goal of Cyclades is to provide an integrated environment for scholars and groups of scholars
that want to use, in a highly personalized and flexible way, open archives, i. e. electronic
archives of documents compliant with the Open Archives Initiative1 (OAI) standard.

The Cyclades system consists of the following services:

• Collaborative Work Service

• Search and Browse Service
• Access Service
• Collection Service
• Filtering and Recommendation Service
• Mediator Service

The Collaborative Work Service provides a folder-based environment for managing metadata
records, queries, external documents, and annotations. Furthermore, it supports collaboration
between Cyclades users by way of folder-sharing in communities and projects. One component
of this service is the Rating Management Service, which manages ratings.
The Search and Browse Service supports the activity of searching records from the various
collections, of formulating and reusing queries, and browsing schemas, attribute values, and
metadata records.
So we can say that system testing a newly written software application or just software, is the
collection of computer programs and related data that provide the instructions telling a computer
what to do. We can also say software refers to one or more computer programs and data held in
the storage of the computer for some purposes. Program software performs the function of the
program it implements, either by directly providing instructions to the computer hardware or by
serving as input to another piece of software. The term was coined to contrast to the old term
hardware (meaning physical devices). In contrast to hardware, software is intangible, meaning it
"cannot be touched".[1] Software is also sometimes used in a more narrow sense, meaning
application software only. Sometimes the term includes data that has not traditionally been
associated with computers, such as film, tapes, and records.
Q5.If you were asked as an expert to provide an estimate of the effort needed
to make certain changes to an existing piece of software, what information would you
like to have to hand to assist you in making that estimate?

1. Estimates of time could be arrived by making enquiries to the manufacturers of the equipment or
machinery.
2. Experts could be consulted to know the involvement of time for maintenance.

3. By identifying and making a list of parts involved in the the equipment or project and making assessment
of the time required for dismantling, cleaning,repairing and assembling back the parts.
Now how to arrive at size / effort. Normally we take a certain percentage of development effort for testing ,
however this is only approximate and needs refinement .In your case where you are doing only testing
project , you can take on representative module / sub module and identify possible test scenario / cases .Going
one more level of details will help you to arrive at effort required for one complete cycle of testing
of this chosen module. Once completed you can extrapolate for other modules and identify the realistic
effort required for testing.
Tests shall be estimated like any other parts of a project: discovering all the work needed and then
estimate the activities (define activities, sequence, estimate duration, resources, etc until the
schedule).
Too many software projects fail. And more of these failures are due to planning inadequacies
than unachievable technical objectives, failed technology, or unachievable
requirements.

A software estimation process that is integrated with the software development process can help
projects establish realistic and credible plans to implement the project requirements and satisfy
commitments. It also can support other management activitiesby providing accurate and timely
planning information. Many elements are involved in determining the structure of a project,
including requirements, architecture, quality provisions, and staffing mix. Perhaps the most
important element in the success or failure of a project are estimates of its scope, in terms of both
the time and cost that will be required and the plans based on those estimates. The estimate
drives every aspect of the project, constrains the actions that can be taken in the development or
upgrade of a product, and limits available options. Although many people think they can estimate
project scope based on their engineering or management experience, most off-the-cuff estimates
are incorrect and are most often based on simple assumptions and over-optimism, or worse, are
made to accord with what others want to hear. Needless to say, such estimates often lead to
disaster.
If the estimate is unrealistically low, the project will be understaffed from its outset and, worse
still, the resulting excessive overtime or staff burnout will cause attrition and compound the
problems facing the project. Overestimation is not the answer. Indeed, overestimating a project
can have the same effects as any other inaccurate estimate. The definition of the verb to estimate
is to produce a statement of the approximate value of some quantity. Estimates are based upon
incomplete, imperfect knowledge and sassumptions about the future.

Q6. Draw an activity network using activity-on-node network conventions for each of
the following project:
a. Choosing and purchasing a desktop computer
b. Organizing and carrying out survey of user’s opinions of an information system.
How do you choose a proper desktop computer system that will meet your computing needs?
There are many factors you'll need to look at before forking your hard-earned cash. Things like
CPU, memory, hard disk space, sound cards are essential factors to consider when selecting the
system. This article will run through each of these factors to help you avoid the many pitfalls that
one may stumble across when purchasing a PC.

Intended Usage

What do you intend to use the computer for? This is one of the key considerations when
purchasing that desktop system. The main goal here is to get a system that will suit your
computing needs. If you're using the computer for professional or business purposes, you'll want
to factor stability and service support into your purchase decision. On the other hand, if you
intend to use the system at home, you may want a more well-rounded PC that can handle
multimedia applications, web surfing easily.

Budget

You'll certainly need to consider your budget buying that PC. Low-end budget systems will save
you a lot of money and are suitable for most home users. High-end systems with the latest Athlon
64 or Intel Pentium 4 processors will cost more and will be more suitable for those who want to
play the latest 3D games or do heavy video or graphics editing.

System Features

OK, here's where it gets complicated. A typical desktop PC has got so many components, it's
hard to decide which system is good or bad. We're talking about a whole plethora of components
from memory, video cards, sound cards, optical drives and so on.

Here's a stab at the most essential components in the PC and what you should look out for:

CPUs
The CPU is the brain of your system - so it's a key consideration when buying that PC. The older
chips like Intel Celeron and Intel Pentium 3 chips are now starting to become obsolete. If you
want your system to last for some time, go for newer processors like the Intel Pentium 4 and
AMD Athlon 64.

a. Organizing and carrying out survey of user’s opinions of an information system.

Task list

A task list is a list of tasks to be completed, such as chores or steps toward completing a project.
It is an inventory tool which serves as an alternative or supplement to memory.

Task lists are used in self-management, grocery lists, business management, project
management, and software development. It may involve more than one list.

When one of the items on a task list is accomplished, the task is checked or crossed off. The
traditional method is to write these on a piece of paper with a pen or pencil, usually on a note pad
or clip-board.

Writer Julie Morgenstern suggests "do's and don'ts" of time management that include:

• Map out everything that is important, by making a task list

• Create "an oasis of time" for one to control
• Say "No"
• Set priorities
• Don't drop everything

This document is a region-based identification guide to the search phase calls of insectivorous
bats from NSW, using the Anabat system. This is based on a library of more than 1200 reference
calls, collected from 31 species throughout NSW over the last four years by the authors and
individual contributors.

Development of the guide was a collaborative effort between the NPWS (part of the Department
of Environment and Conservation) and Forests NSW.

For each species found in NSW there is a description of the known call characteristics, including:

• call shape
• characteristic frequency
• regional notes
• similar species that may be confused on call
• ways to distinguish between similar species
• instances where species cannot be separated on call.
Task list organization

Task lists are often tiered. The simplest tiered system includes a general to-do list (or task-
holding file) to record all the tasks the person needs to accomplish, and a daily to-do list which is
created each day by transferring tasks from the general to-do list.

• A completely different approach which argues against prioritising altogether was put
forward by British author Mark Forster in his book "Do It Tomorrow and Other Secrets
of Time Management". This is based on the idea of operating "closed" to-do lists, instead
of the traditional "open" to-do list. He argues that the traditional never-ending to-do lists
virtually guarantees that some of your work will be left undone. This approach advocates
getting all your work done, every day, and if you are unable to achieve it helps you
diagnose where you are going wrong and what needs to change.

Software applications

Modern task list applications may have built-in task hierarchy (tasks are composed of subtasks
which again may contain subtasks), may support multiple methods of filtering and ordering the
list of tasks, and may allow one to associate arbitrarily long notes for each task.

In contrast to the concept of allowing the person to use multiple filtering methods, at least one
new software product additionally contains a mode where the software will attempt to
dynamically determine the best tasks for any given moment.

Many of the software products for time management support multiple users. It allows the person
to give tasks to other users and use the software for communication .In law firms, law practice
management software may also assist in time management.Task list applications may be thought
of as lightweight personal information manager or project management software.

Attention Deficit Disorder

Excessive and chronic inability to manage time effectively may be a result of Attention Deficit
Disorder (ADD). Diagnostic criteria include: A sense of underachievement, difficulty getting
organized, trouble getting started, many projects going simultaneously and trouble with follow-
through.

• Prefrontal cortex: The prefrontal cortex is the most evolved part of the brain. It controls
the functions of attention span, impulse control, organization, learning from experience
and self-monitoring, among others. Some authors argue that changing the way the
prefrontal cortex works is possible and offers a solution.