Assignment No:-1

CAP-412
Software Project
Management
Submitted to: Submitted by:

Respected Ankur Singh

Sandeep Sharma Sir Roll no:- Re3801a29
 HOMEWORK - 2
PART- A
Q1: What be the should characteristics of the system when
planning a project ?
Ans 1

A project plan can be considered to have five key characteristics that

have to be managed:
• Scope: defines what will be covered in a project.
• Resource: what can be used to meet the scope.
• Time: what tasks are to be undertaken and when.
• Quality: the spread or deviation allowed from a desired standard.
• Risk: defines in advance what may happen to drive the plan off
course, and what will be done to recover the situation.

Q2: Identify the steps for the selection of an appropriate

project approach.

Ans 2
 Data/Process Oriented
– Data: Information Systems, Substantial Database, Relational
Model
– Process: Scientific, Embedded control systems. Object
Oriented
– Hybrid: Both Data & Process Characteristic
  Product/Application Specific
– Product: General Tool, Remote Updates/Helpdesk, Well
Structures
– Application Specific: Niche, Sector, Business Knowledge is
required. Integration, Open Interfaces
 Special Characteristics
– Special Hardware/software requirements
– Safety Critical Application
– Specific tool is required (graphics, expert system, etc.)
 Product Uncertainty
– Requirements are not well defined/Fully documented
– The users do not understand what the software system will do
( potential gap between the users requirements and the
software detailed design)
– Undefined workflows and interrelations among sub
applications
 Process Uncertainty
– Introducing new methods/processes to the project team
– New Application Building Tools
 Resource Uncertainty
– Availability of staff
– Availability of knowledge/experience
 Project type risks
– Availability of funding through the final stage of the project
– Availability & knowledge level of the users
– Clear definition of interfaces, conversion & implementation

Q3: Explain the life cycle model for a project.

Ans 3
Life cycle models describes the inter-relationships between software
development phases.

The common life cycle models are:

* Waterfall Model
* Spiral Model
* V-Model
* Prototyping Model
Since the life cycle steps are described in general terms, the models are
adaptable and their implementation details will vary among different
organizations. The spiral model is the most general. Most life cycle
models can infact be derived as special instances of the spiral model.
Organizations may mix and match different life cycle models to develop
a model more tailored to their products and capabilities.

Waterfall Model

This is also known as Classic Life Cycle Model (or) Linear Sequential
Model (or) Waterfall Method. This has the following features:

* It is least flexible and most obsolete of the life cycle models.

* It is well suited to projects that has low risk in the areas of user
interface and performance requirements, but high risk in budget and
schedule predictability and control.

Stages involved in Software development process:

1. System Engineering and Modeling
2. Software Requirements Analysis
3. Systems Analysis and Design
4. Code Generation
5. Unit Testing
6. Integration Testing
7. System Testing
8. Operation
9. Maintenance

The waterfall model derives its name due to the cascading effect from
one phase to the other as is illustrated in the Figure. In this model each
phase has a well defined starting and ending point, with identifiable
deliveries to the next phase.

System/Information Engineering

As software is always of a large system (or business), work begins by

establishing requirements for all system elements and then allocating
some subset of these requirements to software. This system view is
essential when software must interface with other elements such as
hardware, people and other resources. System is the basic and very
critical requirement for the existence of software in any entity. So if the
system is not in place, the system should be engineered and put in
place. In some cases, to extract the maximum output, the system
should be re-engineered and spruced up. Once the ideal system is
engineered or tuned, the development team studies the software
requirement for the system.

Feasibility:
Defining a preferred concept for the software product and determining
its life-cycle feasibility and superiority to alternative concepts.

Requirements:
A complete, verified specification of the required functions, interfaces,
and performance for the software product.

Product Design:

A complete verified specification of the overall hardware-software

architecture, control structure, and data structure for the product, along
with such other necessary components as draft user's manuals and test
plans.

Detailed Design:

A complete verified specification of the control structure, data structure,

interface relations, sizing, key algorithms and assumptions of each
program component.

Coding:
A complete, verified set of program components. A proper functional
software product composed of the software components.

Implementation:

A fully functioning operational hardware-software system, including

such objectives as program and data conversion, installation and
training.

Maintenance:
A fully functioning update of the hardware-software system repeated for
each update.

Phaseout:

A clean transition of the functions performed by the product to its

successors.

Advantages

* Testing is inherent to every phase of the waterfall model

* It is an enforced disciplined approach
* It is documentation driven, that is, documentation is produced at
every stage

Disadvantages

* It only incorporates iteration indirectly, thus changes may cause

considerable confusion as the project progresses.
* As the client usually has a vague idea of exactly what is required from
the software product, the Waterfall Model has difficulty accommodating
the natural uncertainty that exists at the beginning of the project.
* The customer only sees a working version of the product after it has
been coded which may result in disaster. Any undetected problems are
precipitated to this stage.

Strengths and Weakness of different Software Development Life Cycle

Models:

Waterfall Model:
waterfall performs well for products with clearly understood
requirements or when working with well understood technical tools,
architectures and infrastructures. It's weaknesses frequently make it
inadvisable when rapid development is needed. In those cases,
modified models may be more effective.

Strengths

* Minimizes planning overhead since it can be done up front.

* Structure minimizes wasted effort, so it works well for technically
weak or inexperienced staff.
Weaknesses

* Inflexible.
* Only the final phase produces a non-documentation deliverable.
* Backing up to address mistakes is difficult

Spiral Model
The spiral is a risk-reduction oriented model that breaks a software
project up into mini-projects, each addressing one or more major risks.
After major risks have been addressed, the spiral model terminates as a
waterfall model.

Strengths

* Early iterations of the project are the cheapest, enabling the highest
risks to be addressed at the lowest total cost. This ensures that as costs
increase, risks decrease.
* Each iteration of the spiral can be tailored to suit the needs of the
project.

Weaknesses

* It is complicated and requires attentive and knowledgeable

management to pull it off.

Prototype Models:

Prototyping uses multiple iterations of requirements gathering and

analysis, design and prototype development. After each iteration, the
result is analyzed by the customer. Their response creates the next
level of requirements and defines the next iteration.

Strengths

* Customers can see steady progress.

* This is useful when requirements are changing rapidly, when the
customer is reluctant to commit to a set of requirements or when no
one fully understands the application area.

Weaknesses
* It is impossible to know at the outset of the project how long it will
take.
* There is no way to know the number of iterations that will be required.

Code-and-Fix

If you don't use a methodology, it's likely you are doing code-and-fix.
Code-and-fix rarely produces useful results. It is very dangerous as
there is no way to assess progress, quality or risk. Code-and-fix is only
appropriate for small throwaway projects like proof-of-concept, short-
lived demos or throwaway prototypes.

Strengths

* No time spent on "overhead" like planning, documentation, quality

assurance, standards enforcement or other non-coding activities.
* Requires little experience.

Weaknesses

* Dangerous.
* No means of assessing quality or identifying risks.
* Fundamental flaws in approach do not show up quickly, often
requiring work to be thrown out.

PART - B

Q4: Why budgeting is a important part of project management?

Ans 4
The project scope is the definition of what the project is supposed to
accomplish and the budget (of time and money) that has been created
to achieve these objectives. It is absolutely imperative that any change
to the scope of the project have a matching change in budget, either
time or resources. If the project scope is to build a building to house
three widgets with a budget of $100,000 the project manager is
expected to do that. However, if the scope is changed to a building for
four widgets, the project manager must obtain an appropriate change in
budgeted resources. If the budget is not adjusted, the smart project
manager will avoid the change in scope.

Q5: What are the legal issues that are to be taken care of while
creating a project?
Ans 5

Data Protection Act 1998

Human Rights Acts 1998
Freedom of Information Act 2000
Regulation of Investigatory Powers Act 2000
Computer Misuse Act 1990
Defamation Act 1996
Obscene Publications Act

Legal Issues
Intellectual Property Rights
Copyright
Patents
Trademarks
Duty of Confidence
Scope
8 Data Protection Principles
Annual Notification
Rights of Subjects
Exemptions
Information Commissioner

Data Protection Principles

Processed fairly and lawfully
Processed for specified purpose(s)
Adequate, relevant and not excessive
Accurate, and up to date
Not kept for longer than is necessary
Processed in line with rights of data subjects
Secure from unauthorised access, accidental loss or destruction
Not transferred to countries without adequate protection
Disability Discrimination Act
Q6: Explain the concept of proposal writing.

Ans 6
1. Use outline formats and listings whenever possible to break up
narrative texts.
2. Use visuals to enhance and explain abstract concepts and
relationships. (Do not overuse.)
3. Don't overkill a point. State it, support it, and move on to the next
point.
4. Use forecasting and internal summaries to help the reader know
where they are and where they are going.
5. Be generous with transitions as they will help the reader to know
where they have been and where they are going.
6. Avoid equivocal language, such as: "might, could, ought, may,
should, hope, will consider, it appears".
7. Don't avoid significant issues which apply to the project or potential
problems which may be relevant to the project. It is better to take a
stand and discuss a process for dealing with anticipated problems than
to avoid these questions.
8. Avoid inflated rhetoric or impossible promises.
9. Avoid unsupported subjective arguments.
10. Do not assume that the reader will be intimately familiar with the
subject.