Software Engineering - Unit 1 Notes
1. Introduction to Software Engineering
Definition:
Software refers to instructions (computer programs) that provide the desired features, function,
and performance when executed.
It includes data structures for adequate data manipulation and documentation that describes
the use and operation of the programs.
Key Points:
- Software is developed or engineered, not manufactured.
- Software does not wear out.
- Most software is custom-built, though industry is moving toward component-based
construction.
Software Engineering:
- A systematic, disciplined, and quantifiable approach to development, operation, and
maintenance of software.
- Applies engineering principles to software.
- Focuses on both the product and the process.
2. Evolving Role of Software
- 1970s–80s: Software supported business competitiveness and accessed global networks.
- 1990s–2000s: Rise of electronic communities, shift to information society, concern over
American programmer decline.
- Present: Pervasiveness of computers and software, global knowledge exchange, impact of
global terrorism (9/11), and semantic web evolution.
3. The Changing Nature of Software
Main Software Categories:
1. System Software – Interacts with hardware, supports multiple users, requires complex
scheduling and interfaces (e.g., OS, compilers).
2. Application Software – Solves specific business problems (e.g., POS systems).
3. Engineering/Scientific Software – Used in simulations and design (e.g., CAD).
4. Embedded Software – Controls devices (e.g., automotive systems).
5. Product-line Software – General-use software (e.g., MS Word).
6. Web Applications – Serve various needs through browsers.
7. AI Software – Includes robotics, neural networks, expert systems.
4. New Challenges on the Horizon
1. Ubiquitous Computing – Small devices interconnected globally.
2. Netsourcing – Applications serving global users.
3. Open Source – Self-descriptive, change-tracking code.
4. New Economy – Supports mass communication and product distribution.
5. Software Myths
Management Myths:
- Having documented procedures ensures success (False – only effective if understood and
used).
- Adding more programmers helps meet deadlines (False – requires training and may cause
delays).
- Outsourcing removes the need for oversight (False – internal control is still required).
Customer Myths:
- General goals are enough (False – vague requirements are dangerous).
- Requirements can change freely (False – changes affect cost and quality).
Practitioner Myths:
- Coding completes the job (False – maintenance is 60-80% effort).
- Only code matters (False – documentation supports long-term usage).
- SE slows down development (False – improves quality and reduces rework).
6. Software Engineering as a Layered Technology
1. Quality Focus – Central layer ensuring all other layers function properly.
2. Process – Framework that glues all layers and ensures effective delivery.
3. Methods – Encompasses activities like analysis, design, testing, etc.
4. Tools – Support methods and automate development (e.g., CASE tools).
7. A Generic Process Framework
Framework Activities:
1. Communication – Customer interaction and requirement gathering.
2. Planning – Estimating tasks, resources, and schedule.
3. Modeling – Requirements and design modeling.
4. Construction – Code development and testing.
5. Deployment – Delivery and feedback.
Umbrella Activities:
- Software Project Tracking and Control
- Risk Management
- Software Quality Assurance
- Formal Technical Reviews
- Measurement and Metrics
- Configuration Management
- Reusability Management
- Work Product Preparation and Production
8. Capability Maturity Model Integration (CMMI)
Levels:
- Level 0: Incomplete – No effective process.
- Level 1: Performed – Process is followed but may not be managed.
- Level 2: Managed – Process is planned, monitored, and controlled.
- Level 3: Defined – Process is well-documented and standardized.
- Level 4: Quantitatively Managed – Uses metrics to control quality.
- Level 5: Optimizing – Continuous process improvement.
Specific Goals & Practices:
- SG 1: Estimate project scope, size, and cost.
- SG 2: Develop project plan, identify risks, resources.
- SG 3: Obtain commitment through reviews and agreements.
Generic Goals:
- GG 1 to GG 5 define performance, management, and optimization of processes.
9. Process Patterns
A reusable model for describing software processes.
Components:
- Name: Describes the pattern.
- Intent: Purpose of the pattern.
- Type: Task, Stage, or Phase.
- Initial Context: When the pattern is applicable.
- Problem & Solution: What it addresses and how.
- Resulting Context: Outcome after implementation.
- Known Uses: Real-world examples.
10. Process Assessment Approaches
1. SCAMPI – SEI-based 5-step assessment model.
2. CBA IPI – Internal diagnostic technique.
3. SPICE (ISO/IEC 15504) – Standard for process assessments.
4. ISO 9001:2000 – General quality standard applicable to software.
11. Personal and Team Software Process Models
Personal Software Process (PSP):
- Emphasizes individual accountability and metrics.
- Activities: Planning, High-Level Design, Development, Postmortem.
Team Software Process (TSP):
- Self-directed team with specific roles and responsibilities.
- Activities: Launch, design, coding, integration, test, postmortem.
- Uses scripts and forms for guidance and tracking.
12. Prescriptive Process Models
1. Waterfall Model:
- Linear process: Requirement → Design → Code → Test → Deploy.
- Suitable when requirements are stable.
- Challenges: No early working software, hard to handle changes.
2. Spiral Model:
- Combines Waterfall and prototyping with risk analysis.
- Suitable for large, high-risk systems.
- Involves iterative cycles with anchor points and adjustments.
3. Agile Model:
- Iterative and flexible.
- Short cycles (1–4 weeks), continuous feedback.
- Phases: Requirement Gathering, Design, Construction, Testing, Deployment, Feedback.
Pros:
- Flexible, faster delivery, client involvement.
Cons:
- Less documentation may create confusion.