CS587

Exam
Singh Rishabh
St. Name: _______________, ________________
Last Name, First Name
St. ID:
A20514380

10 points for every question

Q1. What is the purpose of the work package? Who will create
it?

Answer:

The purpose of a work package is to break down a project activity into

smaller, more manageable tasks. This provides us a clear roadmap for
completing the activity and facilitates communication and coordination
among team members. It also ensures we have the right people and
materials for each task, this helps spot potential issues early, and
improves communication among team members.

When generating a work package, the following two persons are

generally involved:
Activity Manager: This individual is principally in charge of defining the
tasks, designating them to particular individuals, and establishing due
dates. They also ensure that the required resources are available and
detect any dependencies between activities.
Project Manager: This individual oversees ensuring that work packages
are created in accordance with the project plan. The job package
documents are examined and approved by them.
Q2. Explain the difference between reviews and audits within
the context of software project management and the software
development process.

Answer: The difference between reviews and audits is given below:

Aspect Reviews Audits

Purpose It detects flaws and It ensures compliance
enhance the quality of with established
software components early processes and
in the development standards.
process
Conducted By It is conducted by Peers External
and managers within the organizations or
organization, mostly auditors who are not
technical experts. directly involved in
the project
Types Formal Group Reviews, Process Audits,
Desk Reviews, Technical Compliance Audits,
Reviews. Quality Audits.
Different Stages It involves Planning, It consists of
Preparation, Meetings, Verification,
Follow-up. Examination,
Checklists phases.
Goal Detecting issues and Detecting process
monitoring progress, non-compliance and
ensuring the software initiating corrective
product adheres to quality actions to maintain
standards by identifying and enhance process
defects early integrity. Emphasizes
verifying adherence
to processes rather
than directly
improving the
product
Q3. When building the project network diagram, can we
schedule the testing phase to start after the design phase?
Explain

Answer: Yes, the testing phase can be scheduled to start after the
design phase. This is based on the concept of Finish-to-Start (FS)
dependency in project scheduling. As per FS dependency, one activity
must finish before the next one can start. Specifically, the design
phase must be completed before the testing phase can begin to ensure
that all design specifications are implemented and ready to be tested.
This type of dependency we typically use during the initial project
planning session to sequence activities logically.
Also as taught in the classroom "The finish to start (FS) dependency
says that activity A must be complete before activity B can begin. The
FS dependency is recommended in the initial project planning session".
"The finish to finish (FF) dependency states that activity B cannot finish
sooner than activity A. For example, Testing (activity B) cannot finish
until Implementation (activity A) has finished".
By scheduling the testing phase to start after the design phase, the
project ensures that the test cases are based on finalized designs, thus
improving the accuracy and relevance of the tests.
Q4. For a software development organization that is CMM
level-3, which method can be used for estimating activity
effort/duration? Explain.

Answer:

For software development companies operating at CMM Level 3, there

are several reliable methods to estimate the effort and duration of
project activities, some common methods used are:

1. Delphi Technique: In this structured communication method, a

panel of experts provides independent estimates, which are then
aggregated and shared until a consensus is reached.

2. Work Breakdown Structure (WBS): In this we break down the

project into smaller, manageable tasks which help in estimating
each task individually, which are then combined to determine
total effort and duration.

3. Analogy-Based Estimation: In this method we compare the

current project with past projects of similar scope and complexity
to predict effort and duration.

4. Top-Down and Bottom-Up Approaches:

Top-Down Approach: Estimations start from the overall project

level and then break down into smaller components.
Bottom-Up Approach: Estimations start at the task level and
aggregate upwards to build the overall project estimate.

Q5. Who controls the design review meeting? What are the
different metrics collected in the requirements review
meeting?

Answer: The Project Manager controls the design review meeting.

They are also responsible for recording decisions and Actions and
setting the agenda and also managing the meeting time for each topic.

During a review meeting, several key pieces of information are

collected to ensure the project’s requirements are solid. These include:
 1. Number of Requirements: Counting how many requirements
there are.
2. Coverage: Making sure all aspects of the project are included.
3. Clarity: Checking that the requirements are clear and not
confusing.
4. Feasibility: Making sure the requirements are realistic and can be
achieved within the project’s limits.
5. Traceability: Ensuring each requirement can be linked back to a
specific need or input.
6. Consistency: Making sure the requirements don’t contradict each
other and fit with the overall project goals.

Q6. From the perspective of software project management,

software artifact review/inspection is only one aspect to
ensure the quality of the software produced, Explain.

Answer: Software artifact review/inspection is indeed an essential

aspect of ensuring software quality, but it is not the only one. Several
other factors and practices contribute to achieving high-quality
software like:

1. Testing: Software testing is essential for finding bugs,

inconsistencies, and other flaws in the program. A range of
testing methodologies, including unit, integration, system, and
acceptance testing, aid in verifying that the software operates as
intended and satisfies the established specifications.
2. Continuous Integration and Deployment: By putting continuous
integration and deployment strategies into practice, developers
may quickly and effectively deliver software updates, perform
automated tests, and integrate code changes on a regular basis.
This raises the standard of software by assisting in the early
detection and resolution of problems during the development
cycle.
3. Change Management: Effectively managing software
modifications helps stop errors and inconsistencies from being
introduced. The methods involved in change management
encompass evaluating the effects of modifications, recording
them, securing authorization, and guaranteeing appropriate
execution and examination.
4. Documentation: Producing thorough and accurate
documentation, such as technical specifications, design
documents, and user manuals, helps guarantee that
stakeholders have the knowledge necessary to comprehend and
operate the software.
Q7. What are the constraints that may influence whether we
can partition an activity or not?

Answer:
Partitioning an activity inside a project may not be feasible due to a
variety of reasons. These limitations consist of:

1. Resource Constraints: The inability to break an activity down into

smaller jobs may be caused by a lack of workers, tools, or supplies. It
might not be possible to provide resources to several subtasks at once
if they are limited or specialized.

2.Time Constraints: It may be difficult to divide work when there are

tight project deadlines or time-sensitive activities. It could be more
effective to continue with the activity if there isn't enough time to plan
and oversee several smaller projects.

3. Cost Constraints: Partitioning operations may result in extra

expenses for managerial overhead, coordination, and communication.
It might not be a good idea to divide an activity if the expenses exceed
the advantages.

4.Technical Constraints: Some tasks could call for specific knowledge

or abilities that are difficult for team members to share. To ensure
correctness and coherence, complex or technical jobs may need to be
handled by a single person or team.

5. Regulatory or Compliance Constraints: In order to guarantee

adherence to regulations, some people or teams may need to manage
activities involving regulatory requirements or compliance standards.
When partitioning such activities, compliance issues may need to be
carefully considered.
Q8. What are the possible actions that the project manager
and moderator might consider to take for the following
outcomes of code inspections?
1. Rework and bug fixes turned out to require more than
50% of the original effort to write the code.

Answer:

If the project manager and moderator come across a situation where

rework and bug fixes require more than half of the initial effort to write
the code, they should immediately begin a comprehensive Root Cause
Analysis. To understand why there needs to be so much rework, it is
necessary to get into the details. In order to identify any gaps or
misconceptions that resulted in the significant rework, this procedure
usually entails evaluating the original requirements, design
documentation, and the development process. Putting Process
Improvement strategies into action is the next step after determining
the core issues. The purpose of these steps is to keep similar problems
from happening in other projects down the road.
A Re-review must also be scheduled in order to confirm that the flaws
found have been sufficiently resolved and to look for any new problems
that may have arisen during the rework phase.

2. Rework and bug fixes turned out to require 15% to 20%

of the original effort to write the code.

When rework and bug fixes account for 15–20% of the initial work, a
distinct set of steps is involved. Monitoring and adjusting the situation
is crucial, to start with. There is still opportunity for improvement even
though this degree of rework falls within a more acceptable range. This
is a critical time to give the developers specific feedback and
communication. Improvements can be substantial if thorough feedback
is provided regarding the kinds of flaws discovered during the
inspection and stronger adherence to coding standards and procedures
is encouraged. Further, it's essential to refine the processes that
already exist. For developers, this can mean making necessary
adjustments and improvements to checklists and procedures so that
more problems are found before they come up during code
inspections.
 3. Rework and bug fixes turned out to require less than 5%
of the original effort to write the code.

A different strategy is needed when rework and bug fixes take less
than 5% of the initial effort. The Best Practices that resulted in this low
amount of rework must be acknowledged and reinforced in such cases.
This may include praising team members who consistently write well-
written code and motivating them to teach others about their methods.
It's also critical to keep your attention on continuous improvement.
Last but not least, it is critical to document the measurements and
successful procedures that went into this achievement. In the end,
better software quality and less rework in later development efforts
result from the sharing and adoption of best practices throughout the
company, which is ensured by this documentation, which also acts as a
model for other teams and projects in the future.
Q9. Consider the following milestone table, what is the
milestone trend chart that the following project follows? Name
and draw the milestone trend chart.

Expected Actual
Milestone Delivery delivery
Project Planning 1st month on-time
Requirement
Phase 2nd month on-time
early 1
Analysis phase 3rd month week
early 1
Design phase 4th month week
early 2
Coding 5th month weeks
early 2
Unit Testing 6th month weeks
Integration early 2
Testing 7th month weeks
early 3
Documentation 8th month weeks
Installation/ early 3
Training 9th month weeks

Answer:
Based on the given milestone table, the project follows a trend of
Successive Runs. This is signaled by the fact that after the Analysis
phase, each subsequent milestone is being completed earlier than
planned, and this early completion continues to increase over time.

The milestone trend chart is given below:

Q10. Consider the following data; calculate the effort and
duration required for every task, considering the following
constraints:

1. An artifact is produced by only one author

2. Every review “meeting” task shall be carried by 5
engineers including the author
3. Every review “preparation” task shall be carried by 4
engineers excluding the author
4. Any “Rework” task can be executed by the author of
the original task
 Answer:
Amount Effort Duration
Tasks of Work Productivity
High Level Design (HLD)
176 88/1=88
pages /2 hours
page
176 2 =88
Write HLD Document pages page/Hour pages/hour
Review HLD Document
Preparation for HLD 4 176/4=44 44/4=11
Document pages/Hour pages /hour hours
176/6=29.3 29.33/5=5.
6 3 86 hours
Review Meeting pages/Hour pages/hour
43/5=8.6 8.6/1=8.6
43 5 defects/hou hours
Rework defects defect/Hour r

Low Level Design (LLD)

2 76/2=38 38/1=38
Write LLD Document 76 pages pages/Hour pages/hour hours
Review LLD Document
Preparation for LLD 3 76/3=25.33 25.33/4=6.
Document pages/Hour pages/hour 33 hours
6 76/6=12.66 12.66/5=2.
Review Meeting pages/Hour pages/hour 53 hours
43/1=43 43/1=43
43 1 defects/hou hours
Rework defects defect/Hour r

Testing
102 5 102/5=20.4 20.4/1=20.
Write Test Plan pages pages/Hour pages /hour 4 hours
Review Test Plan
102/10=10.
Preparation for Test 10 2
Plan pages/Hour pages/hour
15 102/15=6.8 6.6/5=1.36
Review Meeting pages/Hour pages/hour hours
5 75/5=15 15/1=15
75 defects/Hou defects hours
Rework defects r /hour