# data[].attributes.body
2. Software Processes

2.1.  Introduction to Software Process

2.2.  Generic Activities

2.3.  Software Process Model (Waterfall, Interactive/Incremental-Spriral/RUP, Agile)

2.4.  Programming in the large vs. Individual programming

# data[].attributes.headline
6. SOFTWARE VERIFICATION AND VALIDATION 

# data[].attributes.subject
6. SOFTWARE VERIFICATION AND VALIDATION 

# data[].attributes.headline
The A.D.A.B Model in Designing Delivery and Learning Experience

# data[].attributes.subject
The A.D.A.B Model in Designing Delivery and Learning Experience

# data[].attributes.body
A Analysis

Align content to outcomes

Anticipate learner’s needs

Learning context and learning environment analysis

Current advances in the field

Community issues and challenges

D Design

Design connectedness to knowledge, people, environment and the Creator

Design awareness to the world and workplace

Deliver in context – contextual learning, real world

Deliver within a respectful learning environment

A Assess

Assess learning continuously, ipsatively, synoptically with the purpose of improving learning

Evaluate engagement, involvement and interaction with knowledge, people, and environment including respectfulness

Assess essential transversal skills

B Build in Belief

Embed reflection

Espouse values

Engender strong conviction

Enhance faith

# data[].attributes.body
There are seven steps this A.D.A.B Model can be applied by the academics in their delivery and learning, with Step 1 being of utmost importance in the starting of any delivery. The following steps are not necessarily sequential, with Steps 5, 6 and 7 are seen as a unique element in delivery processes.

All in all, the UiTM A.D.A.B Model is a model for designing academic delivery. It supports the embedment of value in delivery and learning to create balanced and holistic students capable of being in sync with the Creator, fellow humans and other living and non-living things in their surroundings.

CIDL | Centre for Innovative Delivery & Learning Development (uitm.edu.my)

# data[].attributes.body
AIO SETP Platform is an All-in-One platform designed to manage every aspect of Software Engineering: Theories & Practice (CPM) teaching and learning efforts. This easy access platform provides all materials related to SETP.

# data[].attributes.body
1. Chapter name and outcomes.
2. Chapter outline.
3. Chapter Notes
4. Mind map
5. Video from YouTube
6. Video - Revision
7. Video - Experience Sharing (Alumni/Industry)
8. Supporting Material
9. Quizlet - Based on Chapter
10. Quizizz - Based on Chapter
11. Sample - Quizizz MCQ
12. Sample - Short Structured Questions
13. Contact Us

# data[].attributes.body
This course introduces the theories and practices of Software Engineering, which includes software processes, requirement analysis, design, programming practices, verification and validation and software evolution for a large system. It also constructs a solid foundation for understanding and application of principles, techniques, technologies and tools in the development of a good software system. To help students understand these concepts, students will work in a team which lead a project flow through the entire software lifecycle.

# data[].attributes.body
1.     Apply theories and principles in software engineering. (C6)

2.     Build software solution with software development documentations (P5)

3.     Demonstrate communication skills in software engineering projects. (A3)

4.     Identify appropriate entrepreneurship mind sets in software engineering projects. (A4)

# data[].attributes.body
1.1. What is Software?
1.2. Systems level considerations and its challenges
1.3. Software Crisis
1.4. The Cost of (software) quality

# data[].attributes.headline
7. VIDEO - EXPERIENCE SHARING (ALUMNI/INDUSTRY)

# data[].attributes.subject
7. VIDEO - EXPERIENCE SHARING (ALUMNI/INDUSTRY)

# data[].attributes.body
Dear Students,

In order to use this platform, please follow the STEPS below.

STEPS :

1. Study the topic and additional material notes

2. Explore mind map as a guide.

3. Watch the video for a better understanding

4. Do the self-assessment to test your understanding of the topic

5. Go through the discussion (if any)

6. Join the telegram group for further discussion on the subject.

# data[].attributes.headline
10 Questions to Introduce Software Engineering

# data[].attributes.subject
10 Questions to Introduce Software Engineering

# data[].attributes.body
https://www.youtube.com/watch?v=gi5kxGslkNc

# data[].attributes.attachment_link.title
10 Questions to Introduce Software Engineering

# data[].attributes.headline
Explains the importance of software engineering

# data[].attributes.subject
Explains the importance of software engineering

# data[].attributes.body
https://www.youtube.com/watch?v=R3NzTt0BTWE

# data[].attributes.body
3. Requirements Engineering

3.1.  Introduction to Requirements Engineering

3.2.  Requirements Specification

3.3.  Requirements Validation

3.4.  •  Requirements Modelling

# data[].attributes.body
Requirements Engineering lecture 1: Overview - YouTube

# data[].attributes.attachment_link.title
Requirements Engineering lecture 1: Overview

# data[].attributes.body
Introduction to Software Development Process Models - YouTube

# data[].attributes.attachment_link.title
Introduction to Software Development Process Models

# data[].attributes.headline
7. VIDEO - EXPERIENCE SHARING (ALUMNI/INDUSTRY)

# data[].attributes.subject
7. VIDEO - EXPERIENCE SHARING (ALUMNI/INDUSTRY)

# data[].attributes.body
4.1.   System design principles

4.2.   Design Paradigm - OOAD

4.3.   Relationships between requirements and designs

4.4.   Software architecture concepts and standard architectures

4.5.   Design Pattern

4.6.   Design modeling

# data[].attributes.headline
3. CHAPTER NOTE - SOFTWARE DESIGN PRINCIPLES 1

# data[].attributes.subject
3. CHAPTER NOTE - SOFTWARE DESIGN PRINCIPLES 1

# data[].attributes.headline
3. CHAPTER NOTE - SOFTWARE DESIGN PRINCIPLES 2

# data[].attributes.subject
3. CHAPTER NOTE - SOFTWARE DESIGN PRINCIPLES 2

# data[].attributes.headline
Software Development Explained With Cars

# data[].attributes.subject
Software Development Explained With Cars

# data[].attributes.body
https://toggl.com/track/developer-methods-infographic/

# data[].attributes.attachment_link.readable_text
Agile development - where does the client involvement stop?

The Waterfall model, where development follows a linear path from nailing down requirements to delivery and maintenance, seems all but gone these days. Unless you're working on particularly big projects, you're better off following an agile development methodology.

The agile mindset is grounded in the fact that clients often don't know what exactly they want from a piece of software. Agile teams work in a transparent manner and keep the client involved in the development process to make sure the end result matches their actual needs as closely as possible.

It's like buying a suit from the shop rather than online - you won't ever know if it fits or how it looks on you until you try it out. And ideally, you'd have a tailor make it fit your shape.

Buying software from an agile team is like getting a tailored suit.

Except that the client wants to pay for a stock suit and if something needs fitting, they want to hold the thread while you needle away.

How to protect your development time

While agile development is about transparency and cooperation, you still need to protect your time. Here's a few things that you may have heard clients say:

"Can I sit with you so we can work on this together?"

"Can we squeeze in (this huge feature) real quick, it's very small and shouldn't be very hard."

"I have a friend who could do this in a day, could we do this at half price?"

"Can we go back to the first version? Also we shouldn't pay for this if we won't be using the code."

These scenarios can cost you a lot of time and money if you don't stand your ground. Your first line of defense is a good project management system.

If you need to be able to respond to unexpected issues or maintenance stuff, use a Kanban board. A Kanban board is essentially a to-do list that imposes a strict limit on how many work items can be in progress at a given time. It's a great system for keeping your team from getting overwhelmed by interruptions - if an unexpected issue occurs you can prioritise it, but otherwise it goes into the queue.

If you don't need to worry about maintenance or if the project isn't made up of many interconnected parts, you can use a Scrum system. Scrum limits a team to working on a highly specific goal in sprints lasting typically between 2-4 weeks. Its whole idea is to keep the team fully focused on their goal.

Both Scrum and Kanban rely on discipline to work, so make sure your client knows you're not using either just to annoy them.
Start tracking development time

# data[].attributes.attachment_link.title
Software Development Explained With Cars

# data[].attributes.attachment_link.description
The Waterfall model, where development follows a linear path from nailing down requirements to delivery and maintenance, seems all but gone these days. Unless you're working on particularly big projects, you're better off following an agile development methodology. The agile mindset is grounded in the fact that clients often don't know what exactly they want from a piece of software.

# data[].attributes.body
5.1.  Coding practices

5.2.  Coding standards

5.3.  Development context: “green field” vs. existing code base

# data[].attributes.body
6.1.  Verification and validation concepts

6.2.  Inspections, reviews, audits

6.3.  Testing fundamentals

# data[].attributes.body
7. Software Evolution

7.1.  Software development in the context of large, pre-existing code bases

7.2.  Software evolution

7.3.  Characteristics of maintainable software