1st Year Computer Science Chapter 1: Introduction to Software Development

1st Year Computer Science Chapter 1 is the chapter examiners use to see whether you treat software as a product with stages, or as “I opened an editor and typed.” Introduction to Software Development is not a list of programming languages. It is the argument that a working program is the last step, not the first: someone named a problem, someone wrote requirements, someone designed, someone coded, someone tested, and someone still has to maintain it.

The PDF on this page is the solved Chapter 1 exercise prepared by Mahmood Khan. Use the article to lock the vocabulary, then close it and write the short questions from memory.

Key concepts

• A program is code; software is the product around the code. Documentation, an installer or repo, test cases, and a person who will fix a bug in June all count. If a long question asks “what is software?” do not stop at “a set of instructions.”
• SDLC is the named path from idea to running system. The phases you must be able to list, in order, are typically requirement gathering, analysis, design, implementation (coding), testing, deployment, and maintenance. Boards punish skipped order more than fancy vocabulary.
• Waterfall commits you to finishing a phase before the next. It fits a fixed board-style brief: “build a result card system with these fields.” Changing the fields after coding has started is expensive, and that cost is the point of the model.
• Agile delivers a thin slice, then another. Daily stand-ups and sprints are details. The idea the paper wants: working software in short cycles, with the client allowed to change priority. Do not write “Agile has no planning.”

Common exam traps

• Treating testing as optional polish. Testing is a phase with types (unit, integration, system, acceptance). “We will test if we have time” is not an answer; it is a risk.
• Claiming Waterfall “easily goes back.” You can return to an earlier phase, but the model’s cost curve says that return is late and expensive. That sentence scores marks. “It is flexible like Agile” does not.
• Mixing verification and validation. Verification asks “did we build it as specified?” Validation asks “did we build the right thing for the user?” A login form that matches the spec but that no student can use has been verified and failed validation.

Worked example: a college attendance app

A principal in Sahiwal wants “an app so teachers mark attendance.” That sentence is not a requirement. Walk it through SDLC the way a constructed-response question expects:

1. Requirements: Who marks? On whose phone? Offline at 8:05 a.m.? Can a student see their own record?
2. Analysis / design: Tables for class, teacher, date, status. A simple screen: pick section → tap present/absent. No fancy dashboard in version one.
3. Implementation: One working slice — mark today’s 1st Year ICS section — before you draw charts.
4. Testing: What happens if two teachers tap the same student? If the clock is wrong? If there is no internet in the hall?
5. Maintenance: Next term the college adds a second shift. The design either absorbs that or you pay for a rewrite.

That story is the chapter. Coding comes later; 10th Class Python notes such as Unit 3: Introduction to Python Programming are for syntax, not for skipping SDLC.

When you have this chapter’s exercise done, open the harder constructed-response set: Unit 1 additional and CR questions. It uses the same SDLC, UML, and testing words under longer marks.

Prepared by Mahmood Khan, MS Cybersecurity — Study E-Hub, Sahiwal. Write the phases once without the PDF. Then download the solved exercise and mark yourself.