Fundamental of Software Engineering: June 2011

19 June 2011

Task 4 - Software Myths

Software Myths mean beliefs about software and the process used to build it - can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. For instance, myths appear to be reasonable statements of fact, they have an intuitive feel, and they are often promulgated by experienced practitioners who "know the score".

However, within this exists some myth which implants wrong idea to us. These myth exists among management, customer as well as practitioner.

Now lets we go through deeply.

MANAGEMENT MYTH

Managers with software responsibility, like managers in most disciplines are often under pressure to maintain budgets, keep schedules from slipping and improve quality. Sometimes this pressure leads managers towards software myth as it lessen the pressure.

An example of management myth is as stated below:

IF WE GET BEHIND SCHEDULE, WE CAN ADD MORE

PROGRAMMERS AND CATCH UP

Many do not realize that the reality behind this myth is that software development is mechanistic process like manufacturing. It is true that when more people is added, a job gets done quicker. However, when new people are added, the one's existing has to spend time educating newcomers and this causes amount of time spent on productive development to be reduced. People can be added only in a planned and well coordinated manner.

CUSTOMER MYTH

Customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. Most of the time, customers believes that software managers and practitioners do little to correct misinformation. Thus it leads to false expectations and dissatisfaction with the developer.

An example of customer myth is as stated below:

SOFTWARE REQUIREMENTS CONTINUALLY CHANGE,

BUT CHANGE CAN BE EASILY ACCOMMODATED BECAUSE SOFTWARE IS FLEXIBLE.

According to the myth, the reality of it is actually software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early, the cost impact is relatively small. However as time passes, the cost impact grows rapidly as the recourse have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.

PRACTITIONER MYTH

Practitioner refers to the person who practices something which could be a profession, an occupation or technique which in this case refers to software development or engineering. Did you know, that long time ago programming was viewed as an art form? Well old ways and attitudes die hard.

An example of practitioner myth is as stated below:

UNTIL I GET THE PROGRAM "RUNNING" I HAVE NO WAY OF ASSESSING ITS QUALITY.

The reality of this myth actually is that we should know that the most effective software quality assurance mechanisms can be applied from the inception of a project such as technical review. Software reviews are a "quality filer" that have been found to be more effective than testing for finding certain classes of software defects.

Message From us:

We hope you can understand what is software myth. Actually there are a lot of software myth that you can find but for us what have been describe above is mostly what we love.

Created by: Santhi A/P Parambalam and Siti Assyifa

13 June 2011

TASK 3

CONCLUSION

For those of us, who about to graduate, naturally, we start thinking about what comes after graduation. The answer is the real world.

In the real world, you have to find a job. If you're looking for a job, discover what you want, then find out if jobs are available or predicted to become available. If there are jobs in the field you desire to join, zero in on the skills required in that profession and enjoy the journey.

You can easily find a job with Jobstreet.com. It is really a wonderful job web site. I think it is one of the best job site. On the other hand, JobStreet.com gives a lot of information which cannot provide others job site. What I like about this site is that the interface is simple and easy to understand. It also has good articles offering advice on improving your career, doing well in the workplace and other work-related issues.

Do a lot of searching, and don’t give up. You will find a job that works for you, and one you enjoy. You may have to take a job you don’t enjoy as much at first, but if you stay persistent, you will find your dream job.

created by : Aema Ismail

Nursakinah Mohd Rosli

Module 2: Software Processes

I found that in this module mostly we learn or study about the Process Model. It is not hard actually to remember the types of Process Model but the problem comes when we need to remember about the characteristics or requirements for every types of the Process Model

But before that let me get you what is actually Software Process. Basically software process is a collection of work activities, actions, tasks which are performed when software is to be created.

Honestly if we just read without understanding what is actually the Process Model for eventhough we done with the discussion in the class. Discuss what requirements for the Process Model but it still make us either me also not really understand.

Too many I can't handle I can't remember till I found that if we really want to understanding the Process Model what we need to do is the TABLE. Simple as you eat. The TABLE which I think is best method to study this module.

What I mean with the TABLE is we list for every Process Model its requirements or characteristic by we simplify it.

Like this *I took an example from what we did in the class*

The reason why I took from what we did in the class because it has been simplify and easy to understand. Than I took from book and paste it on here but but never understand it. Just waste isn't?

Yes and indeed we can study more deep on Process Model for more better understanding but I guess there is no time because we need to catch up other thing also.

Unless we do a PhD research on Process Model then you can go and dive very deep on the Process Model

Okeyh just joking.

FYI, this is how the Process Model Looks like.

A) Waterfall Process Model

B) Prototyping Process Model

C) Spiral Process Model

D) Incremental Process Model

E)Concurrent Process Model

Till now bye!

**Credits Pictures Google**

Created by: Siti Assyifa (SW087271)

module 1.

According to what we have came across this module in class, this module contains the basis things regarding software and software engineering. The subtopic covered in this module would be about:-

The Definition and Nature of Software

Software Application Domains

Legacy Software

Definition of Software Engineering

The Software Process

Software Engineering Practice

Software Myths

With all this topic related module, I was aware that reading through the provided slides notes as well as the book is not essential enough for a better and clear understanding. This is because they are too rich in text and we can't be able to look at the overview of all the things in that topic on a single page. It also avoids us from being able to differentiate the differences of categories.

(e.g Hooker's General SE Principles: There are 7 principles stated under this topic and it has its own explanations. Therefore, putting them in a table such as below will enable an overview for easier understanding and memorizing)

This table could also be done for other sub topics for a clear overview and better picture. Hmmm personally I think, The more we are able to break the contents into group the easier it would be for us.

At the end of the module, come up with a brief and simple mind map which would help you to refresh your mind and show the whole picture of the module.