Software Engineering
Semester IV · BCA 252 · 3 credits
0 / 8
chapters done
-
The syllabus asks for
- What is software?
- Attributes of good software
- Software engineering defined
- Software engineering costs
- Key challenges
- Professional practice and ethics
- Software failures, real photographs and the cost of change
Key points
- Software is more than code, and comes in system, application, embedded, web and AI forms; it can be generic or custom.
- Good software is maintainable, dependable, efficient and acceptable.
- Software engineering is a systematic engineering approach to the whole life cycle; it sits inside the broader field of system engineering.
- Costs are dominated by maintenance and testing; major challenges are heterogeneity, change, security, scale and delivery time.
- Professional practice demands competence, confidentiality and public-interest ethics.
-
The syllabus asks for
- Software processes
- The waterfall model
- Evolutionary development
- Component-based software engineering (CBSE)
- Process iteration: incremental delivery and spiral
- Rapid software development
- The Rational Unified Process (RUP)
- Computer-aided software engineering (CASE)
- Choosing a model
- Pictures of the process models, and the people behind them
Key points
- All software processes contain specification, development, validation and evolution.
- Plan-driven models (waterfall) suit stable requirements; iterative models (evolutionary, incremental, spiral, RUP) accommodate change; agile methods (Scrum, XP) and RAD give speed at the price of documentation.
- CBSE builds from existing components; prototyping reduces requirement risk.
- CASE tools support all phases but do not replace sound engineering.
-
The syllabus asks for
- System and software requirements
- Types of software requirements
- Requirements engineering process
- Elicitation and analysis
- Requirements validation
- Software requirements specification (SRS)
- Feasibility study
- Requirements in pictures: a lesson from the year 2000
Key points
- Requirements are written at user and system levels and divided into functional, non-functional and domain requirements.
- Elicitation uses viewpoints, interviews, scenarios, use cases and ethnography, followed by prioritisation and negotiation.
- Validation uses reviews, prototypes and test-case writing to catch errors early.
- The SRS records the agreed requirements in a standard structure; the feasibility study decides whether to proceed.
-
The syllabus asks for
- Design concepts
- Architectural design
- Procedural design with structured methods
- User interface design
- Design in pictures: people, patterns and diagrams
Key points
- Design concepts (abstraction, modularity, information hiding, refinement, functional independence) aim at modules with high cohesion and low coupling.
- Architectural styles organise the system: repository, client-server, layered, MVC; modules are decomposed by objects or functions.
- Structured design maps DFDs to structure charts by transform or transaction analysis, with fan-in/fan-out metrics and pseudo-code for the detail.
- UI design follows HCI principles; the choice of interaction style and presentation depends on users and tasks, and is validated by evaluation.
-
The syllabus asks for
- Programming languages and development tools
- Good programming practices
- Code metrics
- Coding in pictures: from punched cards to code review
Key points
- Language and tool selection depends on problem, performance, team skill, platform, ecosystem and cost.
- Good code follows a standard, uses clear names, is short and cohesive, handles errors, and is reviewed and tested.
- LOC and Halstead measures describe size and effort but must be interpreted with care.
-
The syllabus asks for
- Verification and validation
- Black-box testing
- White-box (structural) testing
- Levels of testing
- Design of test cases
- Quality management
- Testing in pictures: from the first bug to the V-model
Key points
- Verification checks conformance to the specification; validation checks fitness for the user's needs. Inspections are the most cost-effective defect finders.
- Black-box tests (equivalence classes, boundaries) come from the specification; white-box tests from the structure; cyclomatic complexity gives the minimum number of independent-path tests.
- Testing proceeds from units to integration, system and acceptance (alpha, beta), with regression testing after every change.
- Quality management combines product and process quality, measured by reliability numbers and improved through ISO 9001 and CMM maturity levels.
-
The syllabus asks for
- The evolving nature of software
- Types of maintenance
- Maintenance cost and its factors
- Re-engineering and reverse engineering
- Configuration management (CM)
- Maintenance in pictures: old machines, new demands
Key points
- Used software must evolve; ignoring evolution causes decay (Lehman's laws).
- Maintenance is corrective, adaptive, perfective or preventive, with most effort spent on new or changed functionality, not on fixing faults.
- Maintenance is costly, and effort can be estimated from annual change traffic; re-engineering or replacement is chosen by comparing value and cost.
- Configuration management with baselines, versions and controlled change keeps releases reproducible and traceable.
-
The syllabus asks for
- Management activities and the need for management
- Project planning
- Estimating cost and effort
- Project scheduling
- Risk management
- Managing people
- Project management in pictures: estimates, networks and earned value
Key points
- Software projects are hard to manage because the product is intangible, one-off and changing; management comprises planning, scheduling, costing, monitoring, people and risk.
- COCOMO and function points give effort estimates from size or functionality; they are uncertain and should be re-run as knowledge grows.
- CPM finds the critical path and slack; PERT turns three-point estimates into probabilities of meeting a deadline; EVM measures real progress with CPI and SPI and forecasts the final cost.
- Risk is managed by ranking exposure; people and communication determine more projects than tools do.
No chapter matches. Try another word.
The paper
TU assessment: 60% final examination set by the university, 40% internal (assignments, lab work, attendance). Confirm the split in your college's notice.
Where the hours go
Teaching hours are the board's guide to how much of the paper each part carries.
- Unit 3 · Software Requirement Analysis and Specification10 h
- Unit 4 · Software Design10 h
- Unit 2 · Software Development Process Models8 h
- Unit 6 · Software Testing and Quality Assurance6 h
- Unit 1 · Introduction to Software Engineering4 h
- Unit 7 · Software Maintenance3 h
- Unit 5 · Coding2 h
- Unit 8 · Managing Software Projects2 h