Topic 1 of 9 · Lab I
Team Formation, Project Assignment & Planning
Forming a team, choosing a project, writing the proposal, and planning it: feasibility study, work plan, Gantt chart, budget, risk analysis and roles.
← → move between slides · F full screen · M slide list
Before we start
Why this matters
Most student projects do not fail because of code. They fail in week 9, when nobody knows who was writing the SRS, the diagrams contradict each other and the deadline is Thursday.
This first lab sets up everything that prevents that: a team with clear roles, a project worth doing, and a plan that says what happens each week, what it costs and what could go wrong.
You will also write the first chapter of your report: the proposal.
Outline · Lab I
Topics in this chapter
Select a topic to jump to the slide that explains it.
The big picture
What Design Project I is about
In this course your team takes one software system from an idea to a complete design. You do not just draw diagrams in isolation: every lab adds one chapter to the same project report.
- Running example: the ATM banking system used throughout the lab manual.
- Lab tasks: a Library Management System (and a Student Registration System for class diagrams).
- Lab exercise: the same step applied to your team’s own system, submitted as a report.
The big picture
What Design Project I is about (cont.)
A real project, summarised
Team Pulse designs CampusCare, an appointment system for the university medical centre:
- Proposal: 40-minute queues → book in under 2 minutes; 11-week plan; 80,300 Tk budget.
- LaTeX: one Overleaf report, a chapter per member.
- SRS: 4 user classes, numbered FRs, 6 measurable NFRs.
- SDLC: iterative, 22 of 30 points.
- DFD: Level 0 with 4 entities; Level 1 with 5 processes, 3 stores.
- Use cases: 8 goals; «include» Log in, «extend» Join waiting list.
- Sequence & communication: Book appointment with an alt fragment.
- Class diagram: abstract User; Schedule ◆ Slot.
- Wireframes: 3 Figma screens, tested with 5 users.
Concept 2 of 20
Forming a team
A good team is small enough to coordinate and varied enough to cover every skill the project needs. Most design-project teams have 3–5 members.
- Mix skills: someone who writes well, someone who draws diagrams, someone who codes, someone organised.
- Agree on availability before agreeing on friendship.
- Choose a leader (project manager) who tracks deadlines — not one who does all the work.
- Write a team charter in the first week.
Concept 2 of 20
Forming a team (cont.)
Team formation
The team charter
A one-page agreement the whole team signs in week 1. It prevents most arguments later, because the rules were agreed before anyone was stressed.
| Section | What to write | Example |
|---|---|---|
| Goal | What the team will deliver and the grade it aims for | A complete design report for a library system, aiming for A |
| Roles | Who leads each part | Rahim: leader & SRS · Nadia: UML · Tanvir: LaTeX & UI |
| Meetings | When, where, how long | Sunday 3 pm, 45 minutes, on campus or Google Meet |
| Communication | Channel and expected reply time | Messenger group; reply within 24 hours |
| Decisions | How disagreements are settled | Discuss, then majority vote; the leader breaks ties |
| Work tracking | Where tasks live | A shared Trello board and the Gantt chart |
| If someone misses work | Agreed escalation steps | Reminder → team talk → inform the course teacher |
Team formation
How teams develop: Tuckman’s stages
Psychologist Bruce Tuckman (1965) observed that most groups pass through the same stages. Knowing them helps you recognise that early friction is normal.
| Stage | What it feels like | What helps |
|---|---|---|
| Forming | Polite, unsure, waiting for direction | Charter, clear roles, first small task |
| Storming | Disagreements about scope, workload, ideas | Talk about the problem, not the person; use the agreed decision rule |
| Norming | Shared habits, trust grows | Keep meetings short and regular |
| Performing | Work flows; members help each other | Protect focus, celebrate milestones |
| Adjourning | Project ends | Reflect: what would we do differently? |
Concept 5 of 20
Choosing the project
A good project…
- solves a real problem for real users you can talk to
- fits the time: about 10–12 weeks of part-time work
- has at least two kinds of user (e.g. customer and admin) — richer diagrams
- stores and processes data — needed for DFD and class diagrams
- is your team’s own idea, not copied from seniors
Warning signs
- “A system like Facebook” — far too big
- “A calculator” — too small: one user, no data
- No one on the team understands the domain
- Needs hardware or data you cannot get
- Identical to last year’s submitted project
Concept 5 of 20
Choosing the project (cont.)
Concept 6 of 20
Structure of a project proposal
The proposal convinces the reader that the project is worth doing and can be done. The lab manual’s sections, in order:
Concept 6 of 20
Structure of a project proposal (cont.)
| Section | Question it answers |
|---|---|
| Title & team | What is it called and who is responsible? |
| Introduction / problem analysis | What problem exists today, and for whom? |
| Motivation | Why does it matter now? |
| Objectives | What exactly will the system achieve? |
| Literature review / related work | What already exists, and what is missing? |
| Methodology | How will you build it (model, tools, steps)? |
| Feasibility study | Can it be done — technically, economically, operationally? |
| Main phases & work plan | What will be done, by whom, when? |
| Gantt chart | How does the timeline look? |
| Budget | What will it cost? |
| Risk analysis | What could go wrong, and what is the plan? |
| Expected outcome & conclusion | What will exist at the end? |
| References | Where did facts come from? |
The project proposal
Problem analysis and motivation
Start with the problem, not the solution. The lab manual’s ATM example says: customers of a bank must perform transactions (cash withdrawal, balance enquiry) without a bank clerk, at any time, in public places — and huge amounts of data must be kept efficient, error-free, automated and maintainable.
A useful template for your own problem statement:
Today they [current workaround], which causes [cost or pain].
Show the answer
The project proposal
Writing objectives that can be checked
Objectives state what the finished system will achieve. Make them SMART: Specific, Measurable, Achievable, Relevant and Time-bound.
| Weak objective | SMART objective |
|---|---|
| Make banking easy. | Let a customer withdraw cash in under 60 seconds from card insertion. |
| Build a good library system. | Let a member search the catalogue by title, author or ISBN and reserve an available book online by week 10. |
| Improve security. | Lock a card after three wrong PIN attempts and log every failed attempt. |
The project proposal
Literature review: learning from what exists
A literature review shows you know the field. For a design project it usually has two parts:
- Background facts with sources. The manual cites ATMIA estimates of about 3 million ATMs worldwide — roughly one per 3,000 people — with high density in the USA, Canada, Europe and Japan and growing demand in Asia-Pacific and Latin America.
- Existing systems compared feature by feature, ending with the gap your project fills.
Search Google Scholar, IEEE Xplore and the ACM Digital Library; cite with BibTeX (topic 2).
| Feature | System A | System B | Ours |
|---|---|---|---|
| Online search | ✓ | ✓ | ✓ |
| Reservation | ✗ | ✓ | ✓ |
| Automatic fines | ✗ | ✗ | ✓ |
| SMS reminder | ✗ | ✗ | ✓ |
| Bangla interface | ✓ | ✗ | ✓ |
A comparison matrix makes the gap obvious in one glance.
The project proposal
Methodology: how you will build it
The methodology describes the development approach (an SDLC model — topic 4), the tools, and the main behaviour of the system. The manual recommends prototyping: users see inputs and outputs early and changes happen before the final system is built, which reduces risk because late fixes are expensive.
- Model: prototype / iterative / agile …
- Tools: Overleaf, draw.io, Figma, a language and database
- A block or state diagram of the main flow
The project proposal
Methodology: how you will build it (cont.)
Concept 11 of 20
Feasibility study
A feasibility study compares the proposed system with the current one and asks: should we build this at all? A common checklist is TELOS.
Technical
Do we have the technology and skills? Expected accuracy, response time, growth potential, user-friendliness.Economic
Do benefits exceed costs? Budget, human resources, training, payback period, ROI.Legal
Any laws, licences, data-protection or banking rules?Operational
Will people actually use it? Operation time, reliability, accuracy, retrieval rate.Schedule
Can it be finished by the deadline?Feasibility study
Economic feasibility in numbers
The development cost is pre-filled with the new-system total from the manual’s budget (20,69,000 Tk). The yearly figures are invented for the example.
Concept 13 of 20
Main phases and the detailed work plan
The manual lists the phases of a design project:
- Project proposal and planning
- Requirement specification
- SDLC selection
- Data flow diagram (DFD)
- UML use case diagram
- UML sequence and communication diagrams
- UML class diagram
- Software testing
| # | Task | Weeks | Phase |
|---|---|---|---|
| 1 | Requirement specification & data collection | 1 | Research & planning |
| 2 | Requirement finalisation | 1 | Analysis |
| 3 | System design & modelling | 1 | Design |
| 4 | System modelling & finalisation | 1 | Design |
| 5 | System development (coding) | 1 | Implementation |
| 6 | Testing & feedback | 1 | Testing |
| 7 | Beta version delivery | 1 | Testing |
| 8 | Feedback & requirement change | 1 | Testing |
| 9 | Delivery with documentation | 1 | Deployment |
Work plan from the lab manual. “Responsible person” was “project manager and team members” for every row — in your plan, name a person.
Planning and scheduling
Gantt charts
- A Gantt chart (Henry Gantt, 1910s) lists tasks down the side and time across the top; each task is a bar.
- Overlapping bars = tasks running in parallel (testing starts while coding continues).
- A milestone is a zero-length event (proposal submitted), often drawn as a ◆.
- A dependency means one task cannot start until another finishes (design before coding).
- The critical path is the longest chain of dependent tasks; any delay on it delays the whole project.
Interactive
Build a Gantt chart
Planning and scheduling
Budget planning
A budget lists every cost by category: office costs (meetings, first aid), website, equipment (computers, ATM machines, cameras) and salaries. The manual compares the existing system with the new system to show savings.
- Group costs into categories with subtotals.
- Show one-time costs (equipment) separately from recurring costs (salaries, maintenance) when you can.
- State the currency and period (Tk per project, per month…).
- Add a contingency line (often 5–10%) for surprises.
Interactive
Interactive budget
Concept 18 of 20
Risk analysis
- Identify risks: people, technology, requirements, schedule, cost.
- Analyse: estimate probability and impact (1–5 each); score = P × I.
- Plan a response: avoid (change the plan), reduce (lower P or I), transfer (insurance, vendor) or accept.
- Monitor weekly; risks change.
| Risk | Response |
|---|---|
| A member leaves | Reduce: pair people on each deliverable |
| Laptop dies | Reduce: work in Overleaf / Git, weekly backup |
| Scope creep | Avoid: freeze the SRS; log change requests |
| Tool unfamiliar | Reduce: 1-hour tutorial in week 1 |
Interactive
Risk register
Risk and people
Human-resource planning: the RACI matrix
For each deliverable say who is Responsible (does it), Accountable (signs it off — exactly one person), Consulted (gives input) and Informed (kept up to date).
| Deliverable | Leader | Analyst | Designer | Developer | Documenter |
|---|---|---|---|---|---|
| Proposal | A | R | C | C | R |
| SRS | A | R | C | C | I |
| DFD & UML | A | C | R | C | I |
| Wireframes | A | C | R | C | I |
| Final report (LaTeX) | A | C | C | C | R |
Worked example 1 of 3
Worked example 1
Show the solution
- Design: weeks 2–4.
- Coding can start in week 5.
- Testing needs two weeks of coding (weeks 5–6), so it can start in week 7.
- Critical path: planning → design → coding → testing → delivery. A delay in design pushes everything after it.
Worked example 2 of 3
Worked example 2
Show the solution
- Net benefit per year = 2,40,000 − 60,000 = 1,80,000 Tk.
- Payback = 6,00,000 ÷ 1,80,000 = 3.3 years.
- 3-year cost = 6,00,000 + 3 × 60,000 = 7,80,000; benefit = 3 × 2,40,000 = 7,20,000.
- ROI = (7,20,000 − 7,80,000) ÷ 7,80,000 = −7.7%: not yet profitable after 3 years; it pays back early in year 4.
Worked example 3 of 3
Worked example 3
Show the solution
Practice
Practice (1 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Practice
Practice (2 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Check yourself
Quiz
Resources
Further learning
Hand-picked material to go deeper. Links open in a new tab.
Resources
Further learning (cont.)
Summary
Summary
- A team of 3–5 with mixed skills, clear roles and a signed charter avoids most later conflict.
- Choose a real, data-rich project that fits 10–12 weeks and has at least two kinds of user.
- A proposal states the problem, SMART objectives, related work, methodology, feasibility, plan, budget and risks.
- Feasibility (TELOS): technical, economic, legal, operational, schedule.
- A Gantt chart shows tasks over time; watch dependencies and the critical path.
- Risk score = probability × impact; plan to avoid, reduce, transfer or accept.
- A RACI matrix gives every deliverable exactly one accountable person.