MCA Software Engineering Master Notes
Comprehensive Exam Guide for specified topics
UNIT 1: SYSTEM MODELS & DIAGRAMS
1. DFD (Data Flow Diagram)
A DFD maps the flow of information for any process or system. It uses defined symbols like
rectangles, circles, and arrows to show data inputs, outputs, storage points, and the routes
between each destination.
Symbols:
● Square: External Entity (Source or Sink).
● Circle/Rounded Rectangle: Process (Action taking place).
● Open Rectangle: Data Store (Database/File).
● Arrow: Data Flow.
Levels of DFD:
1. Level 0 (Context Diagram): The highest level. It shows the entire system as a single
process node interacting with external entities. It defines the scope.
○ Example: A "Library System" bubble connected to "Student" and "Admin".
2. Level 1: Breaks the single process node into main sub-processes (e.g., "Issue Book,"
"Return Book," "Calculate Fine").
3. Level 2: Breaks down Level 1 processes into more detailed logic.
2. UML Deployment Diagram
A Deployment Diagram shows the physical hardware "nodes" on which the software "artifacts"
(code, libraries) are deployed. It visualizes the static physical view of the system.
Components:
● Node: A 3D box representing hardware (e.g., Server, Mobile Device).
● Artifact: A specific file/software component (e.g., [Link], [Link]).
● Communication Association: Lines connecting nodes (e.g., HTTP, TCP/IP).
UNIT 2: COST & MAINTENANCE
3. COCOMO I vs COCOMO II
COCOMO (Constructive Cost Model) is a regression model for estimating software cost/effort.
Feature COCOMO I (1981) COCOMO II (2000)
Era Mainframe/Batch processing Modern/Desktop/Web era.
era.
Based On Strictly Lines of Code (KLOC). Object Points, Function Points,
and KLOC.
Development Model Assumes Waterfall Process. Supports Spiral, Agile, and
Feature COCOMO I (1981) COCOMO II (2000)
Iterative models.
Complexity 3 Modes: Organic, 3 Stages: Application
Semi-detached, Embedded. Composition, Early Design,
Post-Architecture.
Flexibility Rigid. Hard to adjust for Flexible. Accounts for code
modern tools. reuse and off-the-shelf
components.
4. Software Maintenance & Types
Maintenance is the modification of a software product after delivery to correct faults, improve
performance, or adapt to a changed environment.
Types of Maintenance:
1. Corrective: Fixing bugs/errors found by users after deployment (e.g., fixing a login
crash).
2. Adaptive: Modifying software to work in a new environment (e.g., Upgrading to run on
Windows 11 or new Chrome version).
3. Perfective: Enhancing features or improving performance based on user requests (e.g.,
Making the search 50% faster). (This consumes the most effort: ~50-60%).
4. Preventive: Refactoring code to prevent future problems (e.g., Cleaning up messy code
to make it easier to update later).
UNIT 3: PROCESS IMPROVEMENT & TOOLS
5. CMM (Capability Maturity Model)
A benchmark developed by SEI (Software Engineering Institute) to measure the maturity of an
organization's software process.
The 5 Levels:
1. Initial: Chaos. No defined process. Success depends on individual "heroes."
2. Managed (Repeatable): Basic project management (tracking cost/schedule) is
established. Success can be repeated on similar projects.
3. Defined: The software process for both management and engineering activities is
documented, standardized, and integrated into a standard organization-wide software
process.
4. Quantitatively Managed: Detailed metrics (data) are collected. Software quality is
quantitatively controlled.
5. Optimizing: Continuous process improvement is enabled by quantitative feedback.
6. CASE (Computer-Aided Software Engineering) Tools
Software used to design and implement other software.
● Upper CASE: Tools for the early stages (Planning, Analysis, Design). Examples:
Diagramming tools, Requirement gathering tools.
● Lower CASE: Tools for the later stages (Coding, Testing, Debugging). Examples:
Compilers, IDEs (VS Code), JUnit.
● Integrated CASE (I-CASE): Tools that cover the entire lifecycle.
7. Reverse Engineering
The process of analyzing software to identify the system's components and their
interrelationships and creating a representation of the system in another form or at a higher
level of abstraction.
● Direction: Code \rightarrow Design \rightarrow Requirements.
● Purpose: To understand legacy code where documentation is lost.
8. Re-engineering
The examination and alteration of a system to reconstitute it in a new form.
● Formula: Re-engineering = Reverse Engineering + Restructuring + Forward Engineering.
● Steps:
1. Take old code.
2. Reverse engineer to understand it.
3. Clean/Restructure it (remove dead code, improve modularity).
4. Forward engineer (write new code) using modern practices.
UNIT 4: PROJECT SCHEDULING
9. Project Scheduling
The activity of distributing the estimated effort across the planned project duration by allocating
resources to specific tasks. It determines "what needs to be done" and "by when."
10. Gantt Chart
A generic bar chart used to illustrate a project schedule.
● X-Axis: Time.
● Y-Axis: Tasks.
● Usage: Shows start and finish dates of elements and summary elements of a project.
11. PERT Chart (Program Evaluation and Review Technique)
A network diagram used when task durations are uncertain. It uses three time estimates:
1. Optimistic time (O): Shortest time.
2. Pessimistic time (P): Longest time.
3. Most Likely time (M): Normal time.
● Formula for Expected Time (T_e):
12. Project Evaluation Review Techniques (PERT)
(See Point 11 - PERT Chart is the visual representation of this technique). It helps in analyzing
the tasks involved in completing a given project, especially the time needed to complete each
task, and identifying the minimum time needed to complete the total project.
13. Critical Path Method (CPM) / Management
A deterministic algorithm for scheduling.
● Concept: Identifies the longest path of planned activities to the end of the project.
● Significance: The Critical Path determines the shortest possible time to complete the
project.
● Slack/Float: Tasks not on the critical path have "slack" (they can be delayed slightly
without delaying the whole project). Tasks on the critical path have zero slack.
UNIT 5: SOFTWARE NATURE & PHILOSOPHY
14. "Software is developed or engineered, it is not manufactured"
● Explanation: Manufacturing involves an assembly line where you build physical copies
(e.g., cars). If you make 1000 cars, you use raw materials for each.
● Software: Is a logical process. Once the first copy is "engineered" (designed and coded),
making 1000 copies costs almost nothing. The effort is in the design, not the production.
● Quality: In manufacturing, quality is checked at the end of the assembly line. In software,
quality must be designed in from the start; you cannot "inspect" quality into a bad design.
15. Software Product vs. Manufactured Product
Aspect Software Product Manufactured Product
Nature Logical / Intangible. Physical / Tangible.
Wear & Tear Does not wear out physically. Wears out over time.
Replication Easy and cheap (Copy/Paste). Expensive (Requires raw
materials).
Change Easy to change (just code), but Hard to change once built.
complex consequences.
16. Justify: "Software continues to be custom built, not generic"
Despite the availability of libraries and components, software is usually custom-built because:
1. Specific Business Rules: Every company operates differently. An off-the-shelf product
rarely matches a company's workflow 100%.
2. Integration Needs: Software must connect with a company's existing legacy systems.
3. Competitive Advantage: Companies want unique features that their competitors don't
have, which requires custom coding.
17. Bathtub Curve & "Software does not wear out"
● Hardware (Bathtub Curve): Failure rate is high at start (infant mortality), drops and stays
low (useful life), and rises at the end (wear out). It looks like a "U" shape (Bathtub).
● Software (Ideal Curve): Failure rate should start high (bugs) and drop to zero and stay
there forever.
● Software (Actual Curve): Software doesn't wear out physically, but it deteriorates due to
change.
○ Explanation: Every time you maintain/change software, you risk introducing new
bugs ("Side Effects"). This causes spikes in the failure rate, creating a "Saw-tooth"
pattern rather than a smooth flat line. This is called Software Entropy.
UNIT 6: INTRODUCTION & PROCESS MODELS
18. Software Engineering Types & Need
● Need:
1. To manage complexity.
2. To reduce cost and time.
3. To ensure quality and reliability.
4. To handle large teams.
● Types: (Refers to types of software like System, Application, Embedded, AI - see Topic 1
notes).
19. Software Crisis
(Refer to notes above). Key Concept: The mismatch between hardware power (increasing
rapidly) and the ability to write good software (lagging behind), resulting in failed projects.
20. Software Process
The structure or set of activities required to develop a software system. Fundamental
activities: Specification, Design/Implementation, Validation, Evolution.
21. SDLC (Software Development Life Cycle)
(Refer to notes above). Planning \rightarrow Analysis \rightarrow Design \rightarrow Coding
\rightarrow Testing \rightarrow Maintenance.
22. Spiral Model (Detailed)
A risk-driven process model generator for software projects.
● Structure: It moves in a spiral. Each loop represents a phase of the software process.
● 4 Quadrants:
1. Objective Setting: Determine goals and constraints.
2. Risk Assessment: Analyze risks and build prototypes to resolve them.
3. Development: Code and test.
4. Planning: Review and plan the next spiral loop.
● Advantages: Excellent risk management, good for large/complex projects, software is
produced early.
● Disadvantages: Expensive, complex, requires risk analysis expertise.
23. Incremental vs. Evolutionary
● Incremental: The requirements are broken down. You build Module A, deliver it. Then
build Module B, deliver it. (Like building a house room by room). The core product is
delivered first.
● Evolutionary: You build a quick version of the whole system (Prototype). You show the
user, they give feedback, you refine it. The system "evolves" over time. (Like sketching a
drawing and then adding color/details).
24. Significance of Prototype Model
1. Clarifies Requirements: Best when the customer doesn't know exactly what they want.
2. Reduces Risk: Identify technical or usability issues early.
3. User Involvement: The user sees a working model immediately, leading to higher
satisfaction.
25. Agile Methodology & Types
Agile is a mindset/philosophy focused on iterative development, collaboration, and change.
Manifesto:
● Individuals and interactions OVER processes and tools.
● Working software OVER comprehensive documentation.
● Customer collaboration OVER contract negotiation.
● Responding to change OVER following a plan.
Types:
1. Scrum: Uses Sprints (2-4 weeks), Scrum Master, Product Owner.
2. XP (Extreme Programming): Focuses on technical practices (Pair programming, TDD).
3. Kanban: Visual workflow management (To Do, Doing, Done).
26. Agile vs. Waterfall
Feature Waterfall Agile
Process Linear / Sequential. Iterative / Incremental.
Flexibility Rigid. Hard to change. Very Flexible. Welcomes
change.
Customer Involved only at start and end. Involved continuously.
Delivery "Big Bang" delivery at the end. Continuous delivery of small
chunks.
Documentation Heavy / Detailed. Lightweight.
27. Role of Management in Software Engineering
Management is the "glue" that holds the project together.
1. People Management: Hiring, motivating, and resolving conflicts.
2. Project Planning: Estimating costs, scheduling tasks (Gantt/PERT).
3. Risk Management: Identification and mitigation of risks.
4. Quality Management: Ensuring the final product meets standards.
