Phases of Project Management and Steps in the First Phase

Definition

Project Management is the process of planning, organizing, directing, and controlling resources (people, equipment, and materials) to meet the technical, cost, and time constraints of a project.

Different Phases of Project Management

The project management process consists of the following phases:

Steps Involved in the First Phase: Initiating / Project Planning

The first phase is the most critical phase where the foundation of the entire project is laid. During this phase, the project is conceptualized and feasibility is determined. The following steps are involved:

Step 1: Defining the Project Goal and Scope

• Clearly identify what the project will deliver
• Define the boundaries of the project (what is included and what is not)
• A scope statement is prepared which is a list of project objectives and deliverables
• Set measurable goals and success criteria
• This step answers the question: "What are we building and why?"

Step 2: Identifying the Project Manager and Team

• A suitable project manager is identified who will be responsible for the entire project
• Key stakeholders and team members are identified
• Roles and responsibilities are assigned to team members
• The right personnel with required skills are selected

Step 3: Feasibility Analysis

Feasibility analysis determines whether the project is worth pursuing. It reduces the number of business options. The three main types are:

a) Economic Feasibility (Cost-Benefit Analysis)

• Analyzes whether the expected benefits equal or exceed the expected costs
• Identifies financial benefits and costs associated with the development project
• Review worksheets are used to record costs and benefits
• These worksheets are used after each phase to decide whether to continue, redirect, or kill the project

b) Technical Feasibility

• Evaluates whether the new system will perform adequately
• Assesses whether the organization has the ability to construct the proposed system
• The amount of technical risk depends on four primary factors:
  • Project size
  • Project structure
  • Development group's experience with the application and technology area
  • User group's experience with systems development

c) Operational Feasibility

• Assesses whether the proposed system will likely solve the business problems or take advantage of opportunities
• Evaluates how the new system will fit into the existing organizational environment

Step 4: Identifying Potential Risks

• Identify potential risks that may affect the project as early as possible
• Assess their probability and impact
• Organizations typically expect a greater return on investment for riskier projects
• Develop mitigation and contingency plans to handle identified risks

Step 5: Project Identification and Selection

• Classifying and ranking projects can be performed by top managers, a steering committee, business units, or the IS development group
• Criteria used to assign merit to a project include: cost, duration, complexity, system size, and focus
• An important evaluation method is Value Chain Analysis
• Factors considered during selection include:
  • Existing systems and ongoing projects
  • Resource availability
  • Evaluation criteria
  • Current business conditions
  • Perspectives of decision makers

Step 6: Setting the Project Baseline

• Determine the scope of the project using a scope statement
• Break down all work required into individual tasks and subtasks with detailed descriptions
• Map out the project schedule with clearly defined due dates and a final deadline
  • A Gantt chart is a good tool for this purpose
• Plan the total cost of the project including hourly rates, available resources, etc.
• The project baseline must be clearly outlined before moving to the next stage

Step 7: Creating the Project Plan Document

• Document all the above information into a formal Software Project Plan (SPP)
• The primary deliverable from this phase is a schedule of specific IS development projects
• Acts as a reference guide throughout the project lifecycle
• Provides assurance that people gave careful consideration to project selection

Incremental Commitment

An important concept in the first phase is incremental commitment, which is a strategy in which the project is reviewed in system analysis and design, and the project is rejustified in each of these reviews. This ensures that only viable projects continue forward.

Conclusion

The first phase (Initiating/Planning) is the most important phase as all other phases depend on it. A well-planned project has higher chances of being delivered on time, within budget, and with expected quality. Poor planning leads to project failure, cost overruns, and missed deadlines. The feasibility analysis conducted during this phase ensures that only projects with genuine business value and technical viability are pursued.

Comparison of Observation vs. Document Analysis & Radical Methods for Requirements Determination

Part 1: Compare and Contrast - Observation and Document Analysis

Both observation and document analysis are methods used during requirements determination in the systems analysis phase. They supplement interviewing by providing additional insights into the current system.

Observation

• The analyst physically watches how users perform their tasks and how the current system operates in real time.
• Provides firsthand, direct evidence of actual workflows, bottlenecks, and informal procedures.
• Useful for understanding undocumented practices that users may not mention in interviews.
• Can reveal discrepancies between what users say they do and what they actually do.
• Limitation: Users may change their behavior when they know they are being observed (Hawthorne effect). It is also time-consuming and may not capture rare events.

Document Analysis

• The analyst examines existing documents, forms, reports, procedure manuals, and organizational records related to the current system.
• As stated in the notes: "By examining existing system and organizational documentation, system analyst can find out details about current system and the organization."
• Documents can reveal:
  • Problems with the existing system
  • Reasons why current systems were designed in a particular way
  • Data flows, inputs, and outputs already in use
• Useful for understanding the formal, documented side of the organization.
• Limitation: Documents may be outdated, incomplete, or may not reflect actual current practice.

Comparison Table

Key Contrast: Observation captures what actually happens, while document analysis captures what is formally recorded. Together, they provide a more complete picture than either method alone.

Part 2: Radical Methods for Determining Requirements

When traditional methods (interviews, observation, document analysis) are insufficient for achieving major improvements, radical methods are used. These methods aim to fundamentally rethink and redesign business processes rather than simply improving existing ones.

1. Business Process Reengineering (BPR)

Definition:

"The overall process by which current methods are replaced with radically new methods is referred to as Business Process Reengineering (BPR)."

BPR does not just improve the existing system -- it completely replaces old methods with new, more efficient ones.

Main Goals of BPR:

• Reorganize the complete flow of data in major sections of the organization
• Eliminate unnecessary steps in existing processes
• Combine steps wherever possible to reduce redundancy
• Become more responsive to future change

Core Idea:

BPR searches for the implementation of radical change in business processes to achieve breakthrough improvements in products and services. It is not about incremental improvement but about fundamental transformation.

2. Identification of Processes to Reengineer

Before reengineering can begin, the analyst must identify which processes need to change.

Steps:

1. Understand key business processes:

   • "Key business processes are the structured set of measurable activities designed to produce a specific output for a particular customer or market."
   • These processes are customer-focused.

2. Identify specific activities within those processes that can be radically improved through reengineering.

3. Disruptive Technologies

Definition:

"Technologies that enable breaking long-held business rules that discourage organizations from making radical business changes are called disruptive technologies."

Approach:

• Problems are first identified, and then solutions are formulated using new technologies.
• Disruptive technologies challenge existing assumptions and allow organizations to redesign processes in ways that were previously impossible.
• Examples include the internet, mobile computing, cloud services, and AI -- technologies that fundamentally changed how businesses operate.

Summary Diagram

Radical Methods
      |
      |--- Business Process Reengineering (BPR)
      |         |--- Reorganize data flow
      |         |--- Eliminate/Combine steps
      |         |--- Improve responsiveness
      |
      |--- Identification of Key Processes
      |         |--- Customer-focused processes
      |         |--- Find activities to reengineer
      |
      |--- Disruptive Technologies
                |--- Break old business rules
                |--- Identify problems first, then solutions

Conclusion

Observation and document analysis are complementary traditional methods for requirements determination -- one capturing real behavior, the other capturing formal records. When these methods reveal that the existing system needs more than minor improvements, radical methods like BPR and disruptive technologies are applied to fundamentally redesign processes and achieve breakthrough results.

DFD for Online Pathology System

Context Diagram (Level 0 DFD)

The Level 0 DFD shows the entire system as a single process with external entities and data flows.

                    Login Credentials
         +--------+<-------------------+
         |        |  Registration Data  |
         |Patient +-------------------->+
         |        |  Test Details       |              +--------+
         +---+----+-------------------->+              |        |
             |    |  Payment Info       | ONLINE       | Doctor |
             |    +-------------------->+ PATHOLOGY    |        |
             |    |  Test Date/Time     | SYSTEM       +---+----+
             |    |<--------------------+                  |
             |    |  Test Report        |                  |
             |    |<--------------------+                  |
             |    |  Doctor Schedule    |                  |
             |    |<--------------------+                  |
             +----+                     +------+-----------+
                                               |
                                        Report via Email

Level 1 DFD

The Level 1 DFD decomposes the system into major processes.

External Entities

• Patient (E1)
• Doctor (E2)

Processes

• P1: Registration and Login
• P2: Test Scheduling
• P3: Online Payment
• P4: Report Generation and Notification
• P5: Doctor Visit Scheduling

Data Stores

• D1: Patient Database
• D2: Test Schedule Database
• D3: Payment Database
• D4: Report Database
• D5: Doctor Database

Level 1 DFD Diagram

                Registration Data
E1 (Patient) -----------------------> [P1: Registration
                                            & Login]
                                            |
                Login Credentials           | Patient Record
             <-------------------------     v
                                        [D1: Patient DB]
                                            |
                Valid Login                 |
E1 (Patient) -----------------------> [P2: Test Scheduling]
                                            |
                Test Details               | Test Entry
             ----------------------->      v
                                        [D2: Test Schedule DB]
                                            |
                Test Date & Time            |
             <-------------------------     |
                                            |
                Payment Info               |
E1 (Patient) -----------------------> [P3: Online Payment]
                                            |
                Payment Confirmation        v
             <-------------------------  [D3: Payment DB]

                                       [P4: Report Generation
                                            & Notification]
                                            |
                                        [D4: Report DB]
                                            |
                Test Report                 |
E1 (Patient) <--------------------------    |
                                            |
                Doctor Visit Schedule       |
E1 (Patient) <------------------------ [P5: Doctor Visit
                                            Scheduling]
                                            |
                                        [D5: Doctor DB]
                                            |
                Report via Email            |
E2 (Doctor)  <------------------------------+

Detailed Level 1 DFD Description

Summary of Data Flows

1. Patient --> P1: Registration data
2. P1 --> Patient: Login credentials
3. Patient --> P2: Test details (after valid login)
4. P2 --> Patient: Test date and time
5. Patient --> P3: Payment information
6. P3 --> Patient: Payment confirmation
7. P4 --> Patient: Test report (after notification)
8. P5 --> Patient: Doctor visit schedule
9. P5 --> Doctor: Report via email

Note: The DFD follows standard Yourdon-DeMarco notation with rectangles for external entities, circles/rounded rectangles for processes, open rectangles for data stores, and arrows for data flows, which is the standard approach followed in system analysis and design curriculum.

Critical Factors Distinguishing Agile Methods from Traditional Methods

Introduction

Agile development was primarily intended to help developers build projects that can adapt to changing requirements quickly, enabling easy and rapid project achievement. Traditional methods (such as Waterfall, SDLC) follow a rigid, sequential approach. The following factors highlight the key distinctions between the two.

Critical Distinguishing Factors

1. Flexibility vs. Rigidity

• Agile: Designed to accommodate transforming/changing requests at any stage of development. Requirements can evolve throughout the project lifecycle.
• Traditional: Requirements are fixed at the beginning. Changes are difficult and costly to incorporate once a phase is completed.

2. Iterative Development vs. Sequential Phases

• Agile: Development proceeds through iterations (short cycles). Even in early phases, a skeletal/outline architecture is built and refined progressively through iterations to the first release.
• Traditional: Follows a strict sequence of phases (requirements → design → implementation → testing → maintenance) where each phase must be completed before the next begins.

3. Customer Involvement

• Agile: Customers are actively involved throughout the project. In the planning phase, developers and customers together agree on delivery dates and solutions to business problems.
• Traditional: Customer involvement is primarily at the beginning (requirements gathering) and at the end (acceptance testing), with minimal interaction in between.

4. Delivery Approach

• Agile: Focuses on early and continuous delivery. The productionizing phase releases the product and improves it by adding features incrementally over time.
• Traditional: The complete product is delivered only at the end of the full development cycle, meaning the customer waits longer to see a working system.

5. Team Skills and Collaboration

• Agile: Requires a highly collaborative, technically strong team with a curious attitude toward the work environment, its problems, technologies, and people (Exploration phase). Team members must be skilled in estimation and adaptive thinking.
• Traditional: Roles are more formally defined and separated. Team members work within their designated phase with less cross-functional collaboration.

6. Project Size and Cost Suitability

• Agile: Best suited for dynamic, medium-to-large projects where requirements are likely to change. Less suitable for cheaper or smaller projects.
• Traditional: More suitable for well-defined, stable projects where requirements are clearly understood from the start, including smaller and cheaper projects.

7. Documentation

• Agile: Emphasizes working software over comprehensive documentation. Less formal documentation is maintained.
• Traditional: Relies heavily on detailed documentation at every phase as a primary deliverable before moving forward.

Summary Table

Conclusion

Agile methods are fundamentally distinguished from traditional methods by their adaptability, iterative nature, and continuous customer collaboration, making them ideal for projects in dynamic environments where requirements are subject to frequent change.

Discounted Payback Period Using Net Present Value

STEP 1 - Given Data

STEP 2 - Solution

Present Value Formula

$$PV_n = Y \times \frac{1}{(1+i)^n} = 60{,}000 \times \frac{1}{(1.15)^n}$$

Discounted Cash Flow Table

Key Observation - Limiting Value

The discounted inflows form a decreasing geometric series. The maximum possible cumulative present value (i.e. as $n \to \infty$, a perpetuity) is:

$$PV_{\max} = \frac{Y}{i} = \frac{60{,}000}{0.15} = Rs.\ 4{,}00{,}000$$

Since the sum of ALL discounted inflows to infinity is only Rs. 4,00,000, and this is less than the initial investment of Rs. 5,00,000, the cumulative discounted cash inflows can never recover the initial investment.

NPV Check

$$NPV = PV_{\max} - I_0 = 4{,}00{,}000 - 5{,}00{,}000 = -,Rs.\ 1{,}00{,}000$$

The NPV is negative (approaches $-1{,}00{,}000$), so the project never breaks even on a discounted basis.

Conclusion

The discounted payback period does not exist at a 15% discount rate.

The present value of all future cash inflows (even summed to infinity as a perpetuity) equals only Rs. 4,00,000, which is less than the initial investment of Rs. 5,00,000. Hence the discounted cash inflows never recover the initial outlay, and the project is not viable at 15% (NPV = -Rs. 1,00,000).

Sequence Diagram for Online Food Ordering System with Online Payment Facility

What is a Sequence Diagram?

A sequence diagram is a type of UML interaction diagram that shows how objects interact with one another and in what order (sequence) those interactions occur over time. It captures the dynamic behavior of the system.

Key Actors and Objects Involved

Sequence Diagram (Textual Representation)

Customer      UI/App        OrderSystem     Restaurant     PaymentGateway    Bank
   |             |               |               |                |             |
   |--login()-->|               |               |                |             |
   |<--loginSuccess()--|        |               |                |             |
   |             |               |               |                |             |
   |--browseMenu()-->|          |               |                |             |
   |<--displayMenu()--|         |               |                |             |
   |             |               |               |                |             |
   |--selectItems()-->|         |               |                |             |
   |--placeOrder()-->|          |               |                |             |
   |             |--createOrder()-->|           |                |             |
   |             |               |--sendOrderDetails()-->|       |             |
   |             |               |<--orderConfirmed()----|       |             |
   |             |<--orderID + totalAmount()--|  |                |             |
   |             |               |               |                |             |
   |--selectPayment()-->|        |               |                |             |
   |--enterPaymentDetails()-->|  |               |                |             |
   |             |--initiatePayment()----------->|                |             |
   |             |               |               |--requestAuth()------------>|
   |             |               |               |                |<--authSuccess()--|
   |             |               |               |<--paymentConfirmed()--|     |
   |             |<--paymentSuccess()--|          |                |             |
   |<--orderConfirmation() + receipt()--|         |                |             |
   |             |               |               |                |             |
   |             |               |--notifyRestaurant()-->|        |             |
   |             |               |               |--prepareOrder()|             |
   |             |               |               |--dispatchOrder()|            |
   |<--deliveryStatus()----------|               |                |             |

Diagram Description (Step-by-Step)

Step 1: Login

• The Customer logs into the system through the UI/App.
• The system returns a login success message.

Step 2: Browse and Select Menu

• Customer browses the menu; the UI fetches and displays menu items.
• Customer selects items and adds them to the cart.

Step 3: Place Order

• Customer clicks Place Order.
• UI sends a createOrder() request to the Order Management System.
• Order system forwards order details to the Restaurant System.
• Restaurant confirms the order back to the Order System.
• UI displays Order ID and total amount to the customer.

Step 4: Online Payment

• Customer selects a payment method (card/wallet) and enters payment details.
• UI calls initiatePayment() on the Payment Gateway.
• Payment Gateway sends an authorization request to the Bank/Card System.
• Bank verifies and returns authorization success.
• Payment Gateway sends payment confirmed back to the Order System and UI.
• Customer receives a payment success message and receipt.

Step 5: Order Fulfillment

• Order System notifies the Restaurant to prepare the order.
• Restaurant prepares and dispatches the order.
• Customer receives real-time delivery status updates.

Summary of Lifelines and Messages

Key Point for Exam: In a sequence diagram, vertical lines are called lifelines, horizontal arrows are messages, and activation boxes (rectangles on lifelines) show when an object is active/processing.

Short Notes

a) Integration Testing

Integration testing is a phase of software testing in which individual software modules or units are combined and tested as a group. It occurs after unit testing and before system testing.

Purpose

The main goal of integration testing is to verify that different modules or components of a system work correctly together, and to detect interface defects between integrated units.

Key Points

• After individual modules are developed and unit tested, they are combined progressively and tested for their interactions.
• It checks data flow between modules, function calls, and shared data structures.
• It helps identify problems such as:
  • Incorrect data passing between modules
  • Mismatched interfaces
  • Timing and synchronization issues

Approaches to Integration Testing

Relation to SDLC

As noted in the implementation phase of SDLC, "programs and the entire system is tested to find and correct errors" -- integration testing is a critical part of this testing activity before the system goes live.

b) Relational Model

The relational model is a way of organizing and representing data in a database using a collection of related tables.

Definition:

"The relational database model represents data in the form of related tables, or relations. Each relation (or table) consists of a set of columns called attributes and an arbitrary number of rows called records."

Key Terminology

Example

Student Table (Relation)

Here, StudentID and Name are attributes, and each row is a record.

Characteristics

• It represents the logical view of how data is stored in relational databases.
• Tables can be related to each other through keys.
• It supports operations such as selection, projection, and join (relational algebra).
• It is the foundation of popular database systems like MySQL, Oracle, and PostgreSQL.
• E-R diagrams can be translated into relational models during the database design process.