So ware Project Management

MODULE-2

1. What are the steps involved in Project scope and planning.

Ans: Following are the steps involved in project scope and Planning.
2. Discuss the different view points of so ware development and Advantages &
Disadvantages of these approaches.
Ans:

3. Explain Spiral Model.

Ans: The Spiral Model is a So ware Development Life Cycle (SDLC) model that provides a
systema c and itera ve approach to so ware development. In its diagramma c
representa on, looks like a spiral with many loops. The exact number of loops of the spiral is
unknown and can vary from project to project. Each loop of the spiral is called a phase of the
so ware development process.
Some Key Points regarding the phase of a Spiral Model:
1. The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks.
2. As the project manager dynamically determines the number of phases, the project
manager has an important role in developing a product using the spiral model.
3. It is based on the idea of a spiral, with each itera on of the spiral represen ng a
complete so ware development cycle, from requirements gathering and analysis to
design, implementa on, tes ng, and maintenance.

The Radius of the spiral at any point represents the expenses

(cost) of the project so far, and the angular dimension represents the progress made
so far in the current phase.

Each phase of the Spiral Model is divided into four quadrants as shown in the above
figure. The func ons of these four quadrants are discussed below:
 Objec ves determina on and iden fy alterna ve solu ons: Requirements are
gathered from the customers and the objec ves are iden fied, elaborated, and
analyzed at the start of every phase. Then alterna ve solu ons possible for the phase
are proposed in this quadrant.
  Iden fy and resolve Risks: During the second quadrant, all the possible solu ons are
evaluated to select the best possible solu on. Then the risks associated with that
solu on are iden fied and the risks are resolved using the best possible strategy. At
the end of this quadrant, the Prototype is built for the best possible solu on.
 Develop the next version of the Product: During the third quadrant, the iden fied
features are developed and verified through tes ng. At the end of the third quadrant,
the next version of the so ware is available.
 Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so-far developed version of the so ware. In the end, planning for the next phase
is started.
Advantages
o High amount of risk analysis
o Useful for large and mission-cri cal projects.

Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly par cular exper se
o Doesn't work well for smaller projects.

4. Explain RAD Model (Rapid Applica on development).

Ans: RAD (Rapid Applica on Development) Model
RAD is a linear sequen al so ware development process model that emphasizes a concise
development cycle using an element based construc on approach. If the requirements are
well understood and described, and the project scope is a constraint, the RAD process enables
a development team to create a fully func onal system within a concise me period.
RAD (Rapid Applica on Development) is a concept that products can be developed faster and
of higher quality through:
o Gathering requirements using workshops or focus groups
o Prototyping and early, reitera ve user tes ng of designs
o The re-use of so ware components
o A rigidly paced schedule that refers design improvements to the next product version
o Less formality in reviews and other team communica on
The various phases of RAD are as follows:
1.Business Modelling: The informa on flow among business func ons is defined by
answering ques ons like what data drives the business process, what data is generated, who
generates it, where does the informa on go, who process it and so on.
2. Data Modelling: The data collected from business modeling is refined into a set of data
objects (en es) that are needed to support the business. The a ributes (character of each
en ty) are iden fied, and the rela on between these data objects (en es) is defined.
3. Process Modelling: The informa on object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business func on. Processing
descrip ons are created for adding, modifying, dele ng, or retrieving a data object.
4. Applica on Genera on: Automated tools are used to facilitate construc on of the
so ware; even they use the 4th GL techniques.
5. Tes ng & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall tes ng me. But the new part must be tested,
and all interfaces must be fully exercised.
When to use RAD Model?
o When the system should need to create the project that modularizes in a short span
me (2-3 months).
o When the requirements are well-known.
o When the technical risk is limited.
 o When there's a necessity to make a system, which modularized in 2-3 months of
period.
o It should be used only if the budget allows the use of automa c code genera ng tools.
Advantage of RAD Model
o This model is flexible for change.
o In this model, changes are adoptable.
o Each phase in RAD brings highest priority func onality to the customer.
o It reduced development me.
o It increases the reusability of features.
Disadvantage of RAD Model
o It required highly skilled designers.
o All applica on is not compa ble with RAD.
o For smaller projects, we cannot use the RAD model.

o On the high technical risk, it's not suitable.

o Required user involvement.

5. Explain Need for Agile methods.

Ans: The need for Agile methods arises from the limita ons of tradi onal heavyweight
methodologies in adap ng to the changing nature of so ware development. Agile
approaches, with their emphasis on itera ve development, flexibility, and customer
collabora on, are be er suited to handle the challenges posed by frequent change requests,
documenta on overhead, and the need for adaptability.

Problems with Tradi onal Heavyweight Methodologies

 Difficulty in Accommoda ng Change Requests: Tradi onal methods rely on a rigid,
upfront design and planning process. Any changes to requirements a er this stage are
difficult and costly to implement. In modern so ware development, change requests
are common, making these methods inefficient.
 Documenta on-Driven Approach: Tradi onal methods emphasize extensive
documenta on, which can consume a significant amount of me and effort. This can
hinder produc vity and delay project melines.
  Rigidity: Tradi onal methods are not well-suited for projects with evolving
requirements and changing project characteris cs. They struggle to adapt to the
dynamic nature of modern so ware development.
Need for Agile Methods
Agile methods address these limita ons by:
 Embracing Change: Agile methods are designed to accommodate change throughout
the project lifecycle. They priori ze flexibility and adaptability, allowing teams to
respond to changing requirements and customer feedback.
 Focus on Value Delivery: Agile methods priori ze delivering working so ware
frequently. This enables teams to get feedback early and o en, ensuring that the
product meets customer needs.
 Collabora on and Teamwork: Agile methods emphasize collabora on between team
members and with customers. This fosters a shared understanding of project goals and
promotes efficient decision-making.
 Con nuous Improvement: Agile methods encourage con nuous learning and
improvement. Teams regularly reflect on their processes and iden fy areas for
improvement, leading to more efficient and effec ve development.
Agile methods provide a more effec ve and efficient approach to so ware development by
addressing the challenges posed by tradi onal heavyweight methodologies. They enable
teams to deliver high-quality so ware products that meet customer needs in a mely and
cost-effec ve manner.

6. List the steps involved in Iden fying ac vity risks.

Ans: : IDENTIFY ACTIVITY RISKS

Step 6.1: Iden fy and quan fy ac vity-based risks
Risks inherent in the overall nature of the project have already been considered in Step 3. We
now want to look at each ac vity in turn and assess the risks to its successful outcome. Any
plan is always based on certain assump ons. Say the design of a component is planned to take
five days. This is based on the assump on that the client’s requirement is clear and
unambiguous. If it is not then addi onal effort to clarify the requirement would be needed.
The possibility that an assump on upon which a plan is based is incorrect cons tutes a risk.
In this example, one way of expressing the uncertainty would be to express the es mate of
effort as a range of values.
A project plan will be based on a huge number of assump ons, and so some way of picking
out the risks that are most important is needed. The damage that each risk could cause and
the likelihood of it occurring have to be gauged. This assessment can draw a en on to the
most serious risks. The usual effect if a problem materializes is to make the task longer or
more costly.
Step 6.2: Man risk reduc on and con ngency measures where ever appropriate It may be
possible to avoid or at least reduce some of the iden fied risks. On the other hand,
con ngency plans specify ac on that is to be taken if a risk materializes. For example, a
con ngency plan could be to use contract staff if a member of the project team is unavailable
at a key me because of serious illness.
Step 6.3: Adjust overall plans and es mates to take account of risks We may change our plans,
perhaps by adding new ac vi es which reduce risks. For example, a new programming
language might mean we schedule training courses and me for the programmers to prac ce
their new programming skills on some non-essen al work.

7. XP, core values of XP, Limita ons of XP.

Ans: Extreme Programming (XP) is an Agile so ware development methodology that focuses
on delivering high-quality so ware through frequent and con nuous feedback, collabora on,
and adapta on. XP emphasizes a close working rela onship between the development team,
the customer, and stakeholders, with an emphasis on rapid, itera ve development and
deployment.
Values of Extreme Programming (XP)
There are five core values of Extreme Programming (XP)

1. Communica on: The essence of communica on is for informa on and ideas to be

exchanged amongst development team members so that everyone has an
understanding of the system requirements and goals. Extreme Programming (XP)
 supports this by allowing open and frequent communica on between members of a
team.
2. Simplicity: Keeping things as simple as possible helps reduce complexity and makes it
easier to understand and maintain the code.
3. Feedback: Feedback loops which are constant are among tes ng as well as customer
involvements which helps in detec ng problems earlier during development.
4. Courage: Team members are encouraged to take risks, speak up about problems, and
adapt to change without fear of repercussions.
5. Respect: Every member’s input or opinion is appreciated which promotes a collec ve
way of working among people who are suppor ve within a certain group.
Limita ons Of Extreme Programming
 Lots of effort. XP requires lots of persistence, crea vity, and lean thinking to adjust the
system to the client’s needs day by day.
 Customer must par cipate. According to the XP framework, at least one client
representa ve must work with the team permanently. Very o en, customer has no
interest and me to do so.
 Rela vely high costs. Pair programming means double salary and can be problema c
for smaller teams with a limited budget. XP teams necessarily include a tracker and a
coach, which increases expenses.
 Time for mee ngs. In extreme programming, mee ngs occur very o en. There are
daily stand-ups that last up to 15 minutes, longer end-of-the-week mee ngs, the
Planning Game at the beginning of each development phase, etc. Communica ng face
to face rather than wri ng messages or documenta on is advisable. Altogether
mee ngs require addi onal me and nerve.
 Loca on restric on. XP projects imply that the customer par cipates in the
development regularly and meets the team face-to-face. This is hard to implement
when the customer has a distant loca on.
 Stress. There is a lot of stress and pressure due to ght deadlines when the code has
to be designed and tested today, not tomorrow. Indeed, this is why the programming
is called ‘extreme.’

8. Explain key roles and responsibili es of scrum model and explain 3 types of scrum
mee ngs.
Ans: Scrum is a widely used project management framework in the rapidly changing field of
Agile development. Scrum Team cross-func onal team in charge of producing high-quality
products. In Agile project management, a Scrum Team is essen al for crea ng high-quality
products quickly. In this ar cle, we will learn about a Scrum Team, its role, structure, and
responsibili es.
Scrum Team Roles and Responsibili es
The structure of a scrum team suggests working together, open communica on, and
adaptability. Usually, it includes the following essen al components:
Product Owner
The team member who understands the needs of the customer and their rela ve business
value is known as the product owner. A er that, They can communicate the customer's needs
and preferences back to the Scrum team. The product owner needs to understand the
product's business case as well as the features that customers desire. To ensure that the team
is correctly carrying out the product vision, he must be accessible for consulta on. The
Product Owner is in charge of overseeing the Product Backlog, which comprises the following
items, and most crucially, he must have the power to make any decisions required to finish
the project:
 Clearly expressing items from the product backlog.
 Arranging the items in the product backlog in order of greatest achievement of
objec ves and missions.
 Maximizing the worth of the work that the team completes.
 Ensuring that everyone can see, understand, and access the product backlog, which
outlines the tasks the team will con nue to work on.

Product Owner
Scrum Master
The scrum master assists in removing any obstacles that might be affec ng the team's
produc vity and in holding members of the team accountable for their commitments to the
company. They reviewed work and deliverables with the team regularly, usually once a week.
A scrum master's job is to coach and inspire team members, not impose rules on them.
A scrum master's responsibili es include:
 Make sure everything goes as planned.
 Remove any barriers that affect output
 Plan the important mee ngs and events.

Development Team
The organiza on provides structure and authority to Development Teams so they can plan
and oversee their own work. The Development Team's overall effec veness and efficiency are
maximized by the resul ng energy. The following traits are present in development teams:
 The Development Team is not given instruc ons on how to convert the Product
Backlog into poten ally release able func onality increments, not even by the Scrum
Master;
 Cross-func onal development teams possess all the teamwork abili es required to
produce a product increment.
 Regardless of the domains that need to be addressed, such as tes ng, architecture,
opera ons, or business analysis, Scrum does not recognize sub-teams within the
Development Team.
 Although each member of the Development Team may have specific exper se and
areas of interest, the Development Team as a whole is ul mately accountable.
Three types of scrum mee ngs:

9. Men on steps involved in stepwise planning and project.

Ans: Refer ques on no: 1.

10. Explain waterfall Model.

Ans: Waterfall approach was first SDLC Model to be used widely in So ware Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of so ware
development is divided into separate phases. In this Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequen ally.
The following illustra on is a representa on of the different phases of the Waterfall Model.

The sequen al phases in Waterfall model are −

 Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specifica on
document.
 System Design − The requirement specifica ons from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
 Implementa on − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its func onality, which is referred to as Unit Tes ng.
 Integra on and Tes ng − All the units developed in the implementa on phase are
integrated into a system a er tes ng of each unit. Post integra on the en re system
is tested for any faults and failures.
  Deployment of system − Once the func onal and non-func onal tes ng is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some be er versions
are released. Maintenance is done to deliver these changes in the customer
environment.
Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
 Phases are processed and completed one at a me.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented
The major disadvantages of the Waterfall Model are as follows −
 No working so ware is produced un l late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjus ng scope during the life cycle can end a project.
 Integra on is done as a "big-bang. at the very end, which doesn't allow iden fying any
technological or business bo leneck or challenges early.
Waterfall Model - Applica on
Every so ware developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situa ons where the use of Waterfall model
is most appropriate are −
  Requirements are very well documented, clear and fixed.
 Product defini on is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.

 Ample resources with required exper se are available to support the product.
 The project is short.

11. Explain the need for Agile methods and Basic principles of Agile methods.
Ans: Need for Agile methods refer ques on no: 5.
Agile Principles
There are 12 agile principles men oned in the Agile Manifesto. Agile principles are guidelines
for flexible and efficient so ware development. They emphasize frequent delivery, embracing
change, collabora on, and con nuous improvement. The focus is on delivering value,
maintaining a sustainable work pace, and ensuring technical excellence.

12 Principles for Agile Methodology

The Agile Alliance defines twelve lightness principles for those who need to a ain agility:
1. Our highest priority is to sa sfy the client through early and con nuous delivery of
valuable computer so ware.
2. Welcome dynamic necessi es, even late in development. Agile processes harness
modifica on for the customer’s compe ve advantage.
3. Deliver opera ng computer so ware o en, from a pair of weeks to a couple of
months, with a preference to the shorter mescale.
4. Business individuals and developers should work along daily throughout the project.
5. The build comes around actuated people. offer them the se ng and support they
have, and trust them to urge the task done.
6. the foremost economical and effec ve methodology of conveyancing info to and
among a development team is face-to-face speech.
7. Working with computer so ware is the primary life of progress.
8. Agile processes promote property development. The sponsors, developers, and users
will be able to maintain a relentless pace indefinitely.
9. Con nuous a en on to technical excellence and smart style enhances nimbleness.
10. Simplicity—the art of maximizing the number of work not done—is essen al.
11. the most effec ve architectures, necessi es, and styles emerge from self–organizing
groups.
12. At regular intervals, the team reflects on a way to become simpler, then tunes and
adjusts its behavior consequently.