Unit-5 Software Project Management
1) Nature of
Software and Software Development:
The nature of the software medium has many consequences for
systems engineering (SE) of software-intensive systems. Fred Brooks has
famously observed that four properties of software, taken together,
differentiate it from other kinds of engineering artifacts (Brooks 1995). These
four properties are
1. complexity,
2. conformity,
3. changeability
4. invisibility.
5. complexity
2)
Conformity: Software,
unlike a physical product, has no underlying natural principles which it must
conform to, such as Newton’s laws of motion.
3)
Changeability: Software
coordinates the operation of physical components and provides most of the
functionality in software-intensive systems.
4)
Invisibility: Software
is said to be invisible because it has no physical properties. While the
effects of executing software on a digital computer are observable, software
itself cannot be seen, tasted, smelled, touched, or heard.
5)
Uniqueness: One other point about the nature of software
that Brooks alludes to, but does not explicitly call out is the uniqueness of
software. Software and software projects are unique for the following reasons:
v
Software has no
physical properties;
v
Software is the
product of intellect-intensive teamwork;
v
Productivity of
software developers varies more widely than the productivity of other
engineering disciplines;
v
Estimation and
planning for software projects is characterized by a high degree of
uncertainty, which can be at best partially mitigated by best practices;
v
Risk management for
software projects is predominantly process-oriented;
v
Software alone is
useless, as it is always a part of a larger system; and
v
Software is the most
frequently changed element of software intensive systems.
2) software development
Software
development is the collective processes involved in creating software programs,
embodying all the stages throughout the systems development life cycle (SDLC).
SDLC methodologies support the design of software to meet a
business need, the development of software to meet the specified design
and the deployment of software to production. A methodology should
also support maintenance, although that option may or may not be chosen,
depending on the project in question.
The waterfall model, the original SDLC method, is
linear and sequential, generally following these stages in order:
1) Identification of required software
2) Analysis of the software requirements
3) Detailed specification of the software requirements
4) Software design
5) Programming
6) Testing
7) Maintenance
2) Analysis of the software requirements
3) Detailed specification of the software requirements
4) Software design
5) Programming
6) Testing
7) Maintenance
3) software quality
Software quality management (SQM) is a management
process that aims to develop and manage the quality of software in such a way so
as the best ensure the product meets the quality standards expected by the
customer while also meeting any necessary regulatory and developer
requirements, if any Software quality managers require software to be tested
before it is released to the market, and they do this using a cyclical
process-based quality assessment in order to reveal and fix bugs before
release. Their job is not only to ensure their software is in good shape for
the consumer but also to encourage a culture of quality throughout the
enterprise.
a) Quality assurance
·
encouraging
documentation process standards, such as the creation of well-defined
engineering documents using standard templates
·
mentoring how to
conduct standard processes, such as quality reviews
·
performing in-process
test data recording procedures
·
identifying standards,
if any, that should be used in software development processes
b) Quality planning
Quality
planning works at a more granular, project-based level, defining the quality
attributes to be associated with the output of the project and how those
attributes should be assessed. Additionally, any existing organizational
standards may also be assigned to the project at this phase.
c) Quality control
·
release testing of
software, including proper documentation of the testing process
·
examination of
software and associated documentation for non-conformance with standards
·
follow-up review of
software to ensure any required changes detailed in previous testing are
addressed
·
application of
software measurement and metrics for assessment
4) Software Quality Assurance
SOFTWARE
QUALITY ASSURANCE (SQA) is a set of activities for ensuring quality in
software engineering processes that ultimately results, or at least gives
confidence, in the quality of software products.
Definition
- quality assurance: Part of quality management focused on providing
confidence that quality requirements will be fulfilled.
SQA
Activities
SQA includes the
following activities:
- Process
definition
- Process
training
- Process
implementation
- Process
audit
SQA
Processes
SQA includes the
following processes:
- Project
Management
- Project
Estimation
- Configuration
Management
- Requirements
Management
- Software
Design
- Software Development
- Software Testing
- Software
Deployment
- Software
Maintenance
Software Quality Assurance encompasses the entire software
development life cycle and the goal is to ensure that the development and
maintenance processes are continuously improved to produce products that meet
specifications. Note that the scope of Quality is NOT limited to just Software
Testing. For example, how well the requirements are stated and managed matters
a lot!
Once the processes have been defined and implemented, Quality
Assurance has responsibility of identifying weaknesses in the processes and
correcting those weaknesses to continually improve the processes.
Capability Maturity Model Integration (CMMI) and ISO 9000 are
some quality management systems that are widely used.
The process of Software Quality Control (SQC)
is also governed by Software Quality Assurance (SQA). Read Differences between Software Quality Assurance and Software
Quality Control.
5) risk reduction
1.
Identify
the risks early on in your project.
·
Review the lists of
possible risk sources as well as the project team’s experiences and knowledge.
·
Brainstorm all
potential risks.
·
Brainstorm all missed
opportunities if project is not completed.
·
Make clear who is
responsible for what risk.
2.
Communicate
about risks
·
Pay attention to risk
communication and solicit input at team meetings to ensure that your team
perceives that risk management is important for the project.
·
Focus your
communication efforts with the project sponsor or principal on the big risks
and make sure you don’t surprise the boss or the customer.
·
Make sure that the
sponsor makes decisions on the top risks, because some of them usually exceed
the mandate of the project manager.
3.
Consider
opportunities as well as threats when assessing risks.
·
While risks often have
a negative connotation of being harmful to projects, there are also
“opportunities” or positive risks that may be highly beneficial to your project
and organization. Make sure you create time to deal with the opportunities in
your project. Chances are that your team will identify a couple of
opportunities with a high pay-off that may not require a big investment in time
or resources. These will make your project faster, better and more profitable.
4.
Prioritize
the risks
·
Some risks have a
higher impact and probability than others. Therefore, spend time on the risks
that cause the biggest losses and gains. To do so, create or use an evaluation
instrument to categorize and prioritize risks.
·
The number of risks
you identify usually exceeds the time capacity of the project team to analyze
and develop contingencies. Therefore, the process of prioritization helps the
project team to manage those risks that have both a high impact and a high
probability of occurrence.
5.
Fully
understand the reason and impact of the risks.
·
Traditional problem
solving often moves from problem identification to problem solution. However,
before trying to determine how best to manage risks, the project team must
identify the root causes of the identified risks.
·
Risk occurs at
different levels. If you want to understand a risk at an individual level,
think about the effect that it has and the causes that can make it happen. The
project team will want to ask questions including:
·
What would cause each
risk?
·
How will each risk
impact the project? (i.e., costs? lead time? product quality? total project?)
·
The information you
gather in a risk analysis will provide valuable insights in your project and
the necessary input to find effective responses to optimize the risks.
6.
Develop
responses to the risks.
·
Completing a risk
response plan adds value to your project because you prevent a threat occurring
or minimize the negative effects. To complete an assessment of each risk you
will need to identify:
·
What can be done to
reduce the likelihood of each risk?
·
What can be done to
manage each risk, should it occur?
·
What can be done to
ensure opportunities are not missed?
7.
Develop
the preventative measure tasks for each risk.
·
It’s time to think
about how to prevent a risk from occurring or reducing the likelihood for it to
occur. To do this, convert into tasks, those ideas that you had identified that
would help to reduce or eliminate risk likelihood.
8.
Develop
the contingency plan for each risk.
·
Should a risk occur,
it’s important to have a contingency plan ready. Therefore, should the risk
occur, you can quickly put these plans into action, thereby reducing the need
to manage the risk by crisis.
9.
Record
and register project risks.
·
Maintaining a risk log
enables you to view progress and make sure that you won’t forget a risk or two.
It’s also a communication tool to inform both your team members, as well as
stakeholders, about what is going on.
·
If you record project
risks and the effective responses you have implemented, you will be creating a
track record that no one can deny, even if a risk happens that derails the
project.
10.
Track risks and their
associated tasks.
·
Tracking tasks is a
day-to-day job for each project manager. Integrating risk tasks into that daily
routine is the easiest solution. You may carry out risk tasks to identify or
analyze risks or to generate, select and implement responses. The daily effort
of integrating risk tasks keeps your project focused on the current situation
of risks and helps you stay on top of their relative importance.
6) Role of project manager in software development
A project manager is a person who has the overall
responsibility for the successful initiation, planning, design, execution,
monitoring, controlling and closure of a project. Construction, petrochemical,
architecture, information technology and many different industries that produce
products and services use this job title.
The project manager must have a combination of skills
including an ability to ask penetrating questions, detect unstated assumptions
and resolve conflicts, as well as more general management skills.
A project
manager is a person who is responsible for making decisions, both large and
small. The project manager should make sure they control risk and minimise
uncertainty. Every decision the project manager makes must directly benefit
their project.
Project
managers use project management software, such as Microsoft Project, to
organise their tasks and workforce. These software packages allow project
managers to produce reports and charts in a few minutes, compared with the several
hours it can take if they do it by hand.
The role of the project manager encompasses
many activities including:
- Planning and Defining Scope
- Activity Planning and
Sequencing
- Resource Planning
- Developing Schedules
- Time Estimating
- Cost Estimating
- Developing a Budget
- Documentation
- Creating Charts and Schedules
- Risk Analysis
- Managing Risks and Issues
- Monitoring and Reporting
Progress
- Team Leadership
- Strategic Influencing
- Business Partnering
- Working with Vendors
- Scalability, Interoperability
and Portability Analysis
- Controlling Quality
- Benefits Realisation