Quiz 1 - Result Summary

The results of the written quiz conducted in week 8 is summarised below. Overall average is 65.72 To : IT1573-01 and IT1573-02 : Well done !! As your class average is above the overall average. Please continue to keep up the good work. To : IT1573-03 and IT1573-04 : Please work harder and I hope you all can do better in the next quiz. Your tutors will return the scripts to you when term starts and we will go through all the questions again.

The next quiz (10%) will be during week 14 on UML and Requirement Management.

Week 9 (starting 10 Dec 2007) - the next posting will be in Jan 2008

We had spent the last 2 weeks to learn about basic UML. UML stands for Unified Modelling Language. It is used internationally to construct software model. Current version is UML2.0. Diagrams are better than Text. Using appropriate software models for the development will:

• facilitate better communication and understanding
• validate correctness against the requirements
• establish a blue-print of the software solution

In this module, we will only focus on how to construct simple class diagrams using basic notations such as:

• Classes with class names, attributes and operations
• Association with details of rolenames, multiplicity
• Generalization

We will learn the Use Case Diagrams and Interaction Diagrams (or known as Sequence Diagrams) when we study Requirement Management and Analysis after the term break.

Consider the following example, a class diagram showing the information of:

• 3 classes : BankAccount, AccountHolder, CashAccount and CreditCardAccount
• Each class is described with its own attributes and operations
• BankAccount is given a role-name of "Saving Account"
• Details of the multiplicity is : ONE BanckAccount belongs to ONE AccountHolder, ONE AccountHolder can only create ONE BankAccount (or Saving Account)
• 3 classes (BankAccount, CreditCardAccount, CashAccount) are related using Generalization which means "is-a-kind-of"

Do the following exercise: Identify three domain classes about the different kind of boats described. Use Unified Modelling Language (UML) to illustrate the details and the relationships among them.

“In general, all boats kept in the inventory can be described by its registration number, the manufacturer and the year of purchase. However, there are 2 special types of boats that need additional information to be stored in the database. These include the power boats which have to be identified by the number of engines and the fuel type. For sail boats, the number of sails have to be recorded.”

Week 7 (starting 26 Nov 2007)

In the last 2 weeks, we have looked into Software Qaulity Assurance (SQA) and Quality Control (QC). The common objective for both are the same - to identify defects as early as possible. However, the 2 are different in focus as highlighted below.

We have also mentioned that we will be focusing on 3 QC activities:

1. Review (we had done a simple review exercise during practical last week)
2. Testing (we focus on Black Box Testing Techniques : Equivalence Partitioning and Boundary Value Analysis)
3. Change Control (we have listed out the steps for a simple Change Control procedure)

The diagram below shows the steps of Change Control.

With that, we have concluded part I of this module (i.e. the general concepts of Software Engineering Practices).

In the next 2 weeks, we will look into Software Modelling using Unified Modelling Language (UML).

Week 6 (starting 19 Nov 2007)

This week, we have discussed during tutorial the PDCA approach to Process Improvement and the overview of Software Quality Assurance (SQA). The following chart explains again the main purpose for each of the phases iin PDCA. This will give you the high level idea to approach continuous process improvement.

During practical, we have exercised the construct of a Pareto chart. This is important as you wil be tested in the coming Quiz and final exam. Pareto charts work in the principle that 80% of the problems or defects are caused by 20% of the sources. The chart allows use to identify that these 80% of the problems or defects so that we can focus our efforts to resolve these critical problems. We have also looked into the cause-n-effect diagram which illustrate how root causes of the problems or defects can be identified. Below shows the suggested solution by IT1573-01 students.

For the coming Quiz in week 8, the scope will include topics covered during lecture, tutorial and practical since week 1 to 5 (i.e. up to and including the Quality tools). The format, as mentioned in last lecture, will have 10 MCQs and at least 5 to 7 short questions. Sample of the questions are also discussed in the lecture (hint - you must know the answers for the sample questions !!) . Bring along calculator as you will need it to construct the pareto chart.

Week5 (starting 12 Nov 07)

Week 5 is self directed learning week and I have plan for you to learn 2 very simple quality tools : Pareto Chart and Cause-n-Effect Diagram. The study materials are already posted to our eLearning portal and you are to complete 2 simple exercises. I have shown below the answer to the exercise for Pareto chart. So can you derive what should be the most critical review defects to look into immediately? As for the exercise for Cause-n-Effect Diagram, I will revie your submissions and published one for your reference.

Week 4 (starting 5 Nov 2007)

This week, we have started to look into some details of the CMMI specifications related to Requirement Management, Project Planning, Project Monitoring and Control Processes in Practical 4. First, let me summarize what is the current situation in the case study. Next, let me briefly highlight some of the best practices mentioned in these 3 processes so that you can have a better idea how to improve the situation. For Project Planning process:

For Project Monitoring and Control and Requirement Management Process:

Hopefully with these additional information, you can understand the 3 process areas better. In fact, by doing the proposal for practical 4, you have also answered the tutorial 3 Q4, 5 and 6.

Next week will be self directed learning...I have posted the relevant materials to learn 2 QA tools - Pareto Chart and Cause-n-Effect Diagram. Happy reading.. 8-)

Week 3 starting 29 Oct 2007

We have learnt the software development life cycle (SDLC) models in the past 2 weeks. This week, we look into the details of processes that will be used in the models. Basically, the processes will provide the detailed work instructions to produce the necessary work products. The following diagram illustrates how processes can be used in the SDLC. You can see from the diagram that some of the processes are specifically for each phase eg, Requirement Management process is for Requirement phase. Whereas other processes such as Monitoring and Control process is to be used throughout all phases.

We further study the overview of CMMI (Capability Maturity Model Integration) which is a model that highlight how various categories of processes can be used to improve the quality of software development processes. It allows organizations to choose the way they want to improve the software processes by adopting the staged or continous representations.

• Staged representation - focus on a set of processes in every step of the maturity levels that enable the organizations to have a predefined and proven improvement path.
• Continuous representation - allows improvements of different processes to be performed at different capability levels based on the organization needs and objectives.

There are many process areas (total 22) in CMMI and they are catogrized into Organizational processes, Project Management processes,, Engineering processes and Support processes. We will only be focusing at the following process areas as they are the fundamentals processes in the software development life cycle.

• Project Planning - this process area is to establish and maintain project plans that define the project activities throughout the development life cycle
• Project Monitoring and Control - this process area is to provide monitor the project progress so that appropriate corrective actions can be taken when the project performance deviates significantly from the plan
• Requirement Management - this process area is to manage the requirements in terms of understanding what the users' needs and identify any inconsistency between the requirements and the work products.

It is important for an enterprising organization to have a proper process improvement framework because:

• an enterprise enviornment is a dynamic business environment
• streamlining the business operations and development approach using well defined standard across the organization level is critical for an effective and efficient company
• the process centre -approach helps to ensure a smoother execution of complex software development projects that brings optimization of business operations such as: planning based on statistics than by experiences, focusing on processes rather than product..etc

To let you have a feel of what process improvement is, the practical in week 4 will require you to study in detailed the process areas of project planning, project monitoring and control, requirement management and then use the recommended best practices to suggest improvement of case study. Your proposal (in power-point slides) should include the following contents. I will let you know when to submit your proposal during the lecture next week.

• Introduction to process improvement (what is it and why we need it?)
• What are the current problems
• What are the recommendataions to resolve these problems
• Explain briefly on the implementation of these best practices

Now that you have some ideas of software proesses, we can move on to use some simple software quality tools that can help us to analyse problems encountered in these proesses. See you next week.

Week 2 (starting 22 Oct 2007)

Thanks to the feedback from some of the students. They felt the blog was too wordy. Ok. I will try to use some diagrams to summarise the main points from now on. As you can see from the diagram below, I have added 2 comments for you to believe that you had made good choices of Recruting skillful people and use the right tools as the top 2 best practices for software development. This blends in very well with DBT as highlighted above. So please do well in your course! This week, we have discussed 2 software development process model :

1. Waterfall (and modified Waterfall)

• This model forms the fundation of all development models and
• Typically phases are Planning, Requirement Gathering, Requirement Analysis, Design, Implementation, Testing and Support.
• Some constraints found for Strictly Waterfall model could be: no concurrent activities is allowed; only deliver at the end of the implementation phase
• To overcome these constraints, we used Modified Waterfall model - i.e. overlapping of relevant phases

2. Unified Process (Iterative and Incremental approach)

• From developers' perspective, this approach means repeating the basic Waterfall processes in each iteration and incrementally build the system functionalities.
• From customers' perspective, this approach provides opportunities for feedback and comments in reviewing the intermediate deliveries of the system. This benefits both developers and customers as they are more involved and build confidence in developing the system.

We illustratred the iterative and incremental development approach by the example of building a Video Rental System where the features to be included are:

1. Store records of all video discs
2. Store records of all customer details
3. Handle daily rental business (i.e. rent and return)
4. Generate monthly sales report

The customer is very sure of the requirements for each of these functions..however, he needs you to deliver the functions incrementally so that he can slowly prepare the necessary records for operations in 6-months’time.

To plan for the iterative and incremental development approach, we will link these functions in sequence so that the intermediate releases are logical. The various iterations are shown in the diagram below.

So by now, you have an idea of what software development models are like. In future, you will come across more other kinds of development models but the fundations are still the same as illustrated in the above 2 models. For practical, we had looked into Microsoft Office 2000 case study to understand how the develpment enviornment evolved for different stages of building the office product suite. Let me just highlight some of the critical factors that made their Office 2000 project successful.

1. define clearly the vision of the project to allow every team members know the common goals and work towards it
2. maintain good working relationships between the project managers, developers and testers
3. adopt milestone driven approach to track the progress
4. use daily build to incrementally link up all the source code
5. conduct code review to identify defects before executing the code

Now that we know the life cycle and process models of software development, we will go into the details of defining the processes next week. Thanks to your co-operation! You had better behaved during this week's lecture. Keep it up!

Week 1 (starting 15 Oct 2007)

For week 1, we have an overview of what software engineering is all about. I hope by completing the tutorial and practical this week, you can have an understanding of what to expect in this module. Lets' recap some of the main points discussed.

1. Software engineering suggests to follow a systematic approach to develop software that is of good quality. Or to put it simply, it enable us how to work as a team using scientific and systematic approach to develop a piece of quality software.
2. A process defines a series of steps to execute a task. It helps to identify the required inputs to do the task and ensures an expected output to be produced.
3. As there are many tasks to be executed in a software development project, there will be many processes to govern each of these tasks. These processes can then be presented as a process model to to show different processes (plan the schedule, gather requirements, coding, testing) that to be used in software development.
4. We used Microsoft Word as an example and deduced that a piece of quality software comes with some good attributes like having easy to use, online help available, basic editing functions (open, save, delete, print, font size, styles, colours), reliable..etc.
5. We also recognised soem challenges faced in software development may include working as a team, having good time management, meeting tight deadlines, having the right technical skills for the development..etc. The best practices in software engineering will help us to address some of these problems.
6. We concluded the overivew by saying that having a well defined software development process in the enterprising organizations is critical as it helps to overcome the potential challenges and increase chances of project success.

In the practical, we have read about the 10 Best Practices recommended for Software Development Project. They are listed below. Best practices, derived from the past experiences, are the effective and efficient way of doing things. By following these best practices, we hope to aviod the problems which would have been encountered. I have also asked you to identify 2 B.P. that you think will be most useful in projects. The consolidated outcome is indicated above. The number in brackets are your selections.

1. Recruit skilled and experienced people (51)
2. Use 'leading-edge', not 'bleeding-edge' technology (1)
3. Use the approprite development process (12)
4. Provide the right tools (41)
5. Use source-control management (4)
6. Apply sound estimating techniques (3)
7. Break efforts into mini-milestone tasks (17)
8. Track all project hours (18)
9. Understand the only constant is change (2)
10. Provide project leadership (35)

We can conclude the top 6 choices of the best practices from the students are:

1. Recruit skilled and experienced people
2. Provide the right tools
3. Provide project leadership
4. Track all project hours
5. Break efforts into mini-milestone tasks
6. Use the approprite development process

The first 3 choices don't come as surprises to me. But it was the other 3 that make me feel glad. Because they are going to be taught in this module! There is a matching of customers' needs to my product (It1573). Great! I have also conducted an activity on Requirement Gathering (about 20min) during practical to let that you experienced 'how difficult' it can be to know what the customers really want for their intended system. Two scenario were created separately for 2 practical sessions.

1. To generate a monthly summary report for the medical claim of the Medical Claim System in Visible Sound Pte Ltd (Wednesday)
2. To capture the rental policy of the Rental System for Visible Disc Pte Ltd (Thursday)

Generally, in the first session, the students found it difficult to start off. Probably you are not familiar with the domain. Whereas for session 2, students could ask a lot more relevant questions. I think the main reason is that Rental System is a very typical system like our Library portal. Students are already familiar with the domain. So we can conclude from this exercise that:

1. Having the relevant domain knowledge helps in understanding the requirements better
2. Interviewing customers is one of the ways to get more detailed requirements (other alternative can be through survey)
3. It is important to know the correct requirements right at the beginning

We had fun in these activities. Thanks for your participations! I took the chance also to introduce to you our Centre for IT Innovation (CITI) as you are representing the project leader from the centre to do the interviewing. Be patient, you will get to work there in 3 years' time! We had a good start but lets's have even more fruitful learning experiences in the coming week! One thing I hope for improvement is that -- Please dont talk during lecture..its very disturbing to me ..ok?