Sunday, July 24, 2011
Unknown
4 years ago
24 July 2011
15 July 2011
08 July 2011
30 June 2011
Defendsive Programming
1. Handle unexpected conditions
2. Process external systems data properly
3. Test your code
4. Monitor your site errors and act upon them
5. Do not disclose errors to the users
6. Damage control
7. Backup
8. Do what you can as you can never get defensive enough
* Recommended reading
http://en.wikipedia.org/wiki/Defensive_programming
http://gettingreal.37signals.com/ch09_Get_Defensive.php
2. Process external systems data properly
3. Test your code
4. Monitor your site errors and act upon them
5. Do not disclose errors to the users
6. Damage control
7. Backup
8. Do what you can as you can never get defensive enough
* Recommended reading
http://en.wikipedia.org/wiki/Defensive_programming
http://gettingreal.37signals.com/ch09_Get_Defensive.php
26 June 2011
Task 2 - Module 4 - Software Design
- Method Use To Study : Build a few group to discuss about this topic.
- Topic Should Be Added or Drop: Everything in this topis are good and enough.
- Suggestion About another Teaching Technique: Read text book before come to class. Do research about this topic in internet. Try to answer the question in text book.
- Lesson Learned From This Module:
21 June 2011
Task 2 - Module 3 - Requirement Engineering
- Method Use To Study : Give some example about the theory and situation of this topic. Then we need to discuss.
- Topic Should Be Added or Drop: Everything in this topic is enough.
- Suggestion About another Teaching Technique: Read text book before come to class. Do research about this topic in internet.
- Lesson Learned From This Module:
15 June 2011
Task: 4 - Myth
- Discuss one software engineering myth from each category of management myths, customer myths and practitioner myths (refer slide and textbook).
- Upload the discussion in your blog by the given deadline.
- Provide examples and other materials to support your discussion.
Myth is all about legend or something we recognize as a part of tales that continuously go along the time, somehow the fact could be true or false but it is still become famous among the others who believe with it. In other word it’s may be good otherwise it’s become worth. In term of software management, the myth will goes around the meaning of quality management, cost of belonging, time that under going to be pursuing , thus who suppose to be able to use in term of the last user and a lot of matter will come out by currently idea that been exposed in our mind. Talk about discussion even though the discovery should have a reason and the idea naturally goes at random without curious about the order. Actually, their had many kind of myth but according to our task 4 we suppose to discuss about those three type of myth :-
1) Software management myths
2) Customer myths
3) Practitioner myths
1) Software management myths
Myth 1: Risk of losing data with an Electronic Quality Management System
One of the more persistent myths associated with QMS systems involves the perception that the electronic storage of data is somehow riskier than retaining paper versions of the data. In fact, electronic documents are far safer than any other methods of documentation. Ask yourself a question: Do you back up the files in your cabinet every day? Probably not, but with an electronic QMS, you can create a backup of all your data every night, therefore ensuring that your data is always safe and secure. Do you have a copy of your paper system off site? With an electronic QMS, this is normal - or at least it should be.
When you are looking for ways to save administrative costs, increase employee productivity, improve business performance, and speed up the customer response process, an electronic QMS is a must-have. Deploying a QMS through on-demand / SaaS solution is a hassle-free and cost-effective route for small and medium sized enterprises.
Myth 2: Allocating extra resources to a late project allows it to catch up with the project schedule.
A software project is not a mechanical process such as, say; digging an artificial lake. In case of creating an artificial lake, adding more people to the job can help dig a larger area in the same time. However, in a software project, adding, more people actually increases the time required to finish the project. This happens because a new person joining the project requires time to understand the requirements of the client, software design, and standards. Moreover, the existing people in the project need to devote time and effort to train the new people on the software project. Therefore, allocating additional resources to a risky situation increases the risk to the software project.
Myth 3: As software by itself is flexible, changes in the requirements can be made at any point in the software project life cycle.
Requests for changes are common with all projects. However, the timing of the change for requests is critical. This is because an untimely change adversely, impacts the cost of the software project. For example, a change request during the requirements gathering stage has a relatively low impact on costs. On the other hand, a change request during, the software construction stage can be extremely expensive to incorporate. The software project manager must decide with the customer upon a set of objectives that must be achieved at the end of the project. In addition, the project manager and the customer must decide on a specific phase, beyond which only critical change requests are accepted.
Myth 4: Deploying an Electronic Quality System can cost companies huge sums of money
The demand for quality management software has increased the competition amongst vendors. Companies can select an electronic QMS at an affordable price. Many vendors now offer less-expensive, cost effective quality management software through services such as on demand / SaaS, where the software is hosted on the vendor's server. Additionally, this reduces the cost of ownership by over 60% and makes the implementation possible in days, rather than weeks, all for a small monthly fee.
2) Customer myths
3) Practitioner myths
1) Software management myths
Myth 1: Risk of losing data with an Electronic Quality Management System
One of the more persistent myths associated with QMS systems involves the perception that the electronic storage of data is somehow riskier than retaining paper versions of the data. In fact, electronic documents are far safer than any other methods of documentation. Ask yourself a question: Do you back up the files in your cabinet every day? Probably not, but with an electronic QMS, you can create a backup of all your data every night, therefore ensuring that your data is always safe and secure. Do you have a copy of your paper system off site? With an electronic QMS, this is normal - or at least it should be.
When you are looking for ways to save administrative costs, increase employee productivity, improve business performance, and speed up the customer response process, an electronic QMS is a must-have. Deploying a QMS through on-demand / SaaS solution is a hassle-free and cost-effective route for small and medium sized enterprises.
Myth 2: Allocating extra resources to a late project allows it to catch up with the project schedule.
A software project is not a mechanical process such as, say; digging an artificial lake. In case of creating an artificial lake, adding more people to the job can help dig a larger area in the same time. However, in a software project, adding, more people actually increases the time required to finish the project. This happens because a new person joining the project requires time to understand the requirements of the client, software design, and standards. Moreover, the existing people in the project need to devote time and effort to train the new people on the software project. Therefore, allocating additional resources to a risky situation increases the risk to the software project.
Myth 3: As software by itself is flexible, changes in the requirements can be made at any point in the software project life cycle.
Requests for changes are common with all projects. However, the timing of the change for requests is critical. This is because an untimely change adversely, impacts the cost of the software project. For example, a change request during the requirements gathering stage has a relatively low impact on costs. On the other hand, a change request during, the software construction stage can be extremely expensive to incorporate. The software project manager must decide with the customer upon a set of objectives that must be achieved at the end of the project. In addition, the project manager and the customer must decide on a specific phase, beyond which only critical change requests are accepted.
Myth 4: Deploying an Electronic Quality System can cost companies huge sums of money
The demand for quality management software has increased the competition amongst vendors. Companies can select an electronic QMS at an affordable price. Many vendors now offer less-expensive, cost effective quality management software through services such as on demand / SaaS, where the software is hosted on the vendor's server. Additionally, this reduces the cost of ownership by over 60% and makes the implementation possible in days, rather than weeks, all for a small monthly fee.
When considering the use of a QMS, senior management will usually question the QMS's potential return on investment. Various studies show that using software for quality management can save administrative time, reduce printing costs, improve production cycles, speed up change control processes, and improve speed of response - all of which adds up to a considerable return on investment. One of the biggest costs relates to risk; a good QMS will substantially reduce the risk of incorrect documentation like specifications or inspections being used and can thus provide a difficult to quantify, yet significant savings. Depending on the scope of implementation, a QMS can offer return on investment in as little as 12 months.
Myth 6: Only Technical Personnel can use Quality Management Software
It is a common misconception that anything relating to software is in the realm of an organization's technical team. It gives rise to this myth that only IT departments / technical personnel of companies can handle and use electronic quality systems. The fact is, there are quality management programs which are designed for everyday users who are familiar with internet usage - programs designed to be user-friendly and intuitive. In essence, anyone who can surf the internet can easily use a well-designed electronic QMS system. Further, quality management software is far easier to use than a paper-based system, as the QMS software will typically include help manuals and technical support. Moreover, deploying software through an on demand service doesn't even require an IT department, as the vendor has a support team that installs and implements the software.
Myth 7: Electronic Quality Systems are only for big companies
This prevalent myth asserts that an electronic QMS is designed and meant only for large organizations with multiple sites. The fact is, that in such a competitive environment, it is mandatory for every organization to track and control documents, manage non-conformances, and adhere to regulatory requirements - whatever the company size, amount of locations, or number of employees. All companies must demonstrate the highest standards and quality to auditors if they are to be certified to a standard that meets industry regulations, as well as customer demands. Achieving these goals can be easy with an electronic QMS that ensures continuous improvement, critical information security, issue visibility, quick problem resolution, and fast regulatory approval .In order to effectively and efficiently market new products.
2) Customer myths
A 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. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths led to false expectations and ultimately, dissatisfaction with the developers.
Myth 1: A general statement of objectives is sufficient to begin writing programs we can fill in details later.
Reality : Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.
Myth 2: Project requirements continually change, but change can be easily accommodated because software is flexible.
Reality : It's true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly - resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.
3) Practitioner myths
Myth 1: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code’,the longer it’ll take youto get done.” Industry data ([LIE80] [JON91] [PUT97]) indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.
Myth 2: The only delecerable work prduct for a successful project is the working program.
Reality: Aworking program is only one part of a software configuration the includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.
14 June 2011
Task 3 (Analyzing Jobstreet)
Job title | June 1 | June 2 | June 3 | Advertiser | Descriptions | Requirement | Salary (RM) |
Software engineer | 7 | 14 | 8 | - Chrisjac Recruitment Services - Financial Link Sdn Bhd - Infineon Technologies Asia Pacific - Bsmart Technology Sdn Bhd - Freeborders Malaysia Sdn. Bhd. - Sony EMCS (Malaysia) Sdn. Bhd. - microhandling international sdn bhd | - Plan, develop, implement and evaluate software application (Web-based or desktop solution). - MS SQL server database application development and customization. - Documentation on software development processes and maintenance. - Involve in automation programming on test and measurement system with R&D team in audio/video entertainment products technologies. - Majoring in networking discipline will be focusing on support, develop and propose networking solution as well as providing technical support on R&D audio network product design environment. - Knowledge on Cisco switches, LAN, WAN networking will be an added advantage on this addition position. | -Bachelor’s degree in computer science, electrical/electronic engineering, software engineering, information technology, information system or equivalent. - Possess knowledge in VB.NET and ASP.Net programming. - Strong analytical skills, creative thinking with the ability to work independently and effectively as a team. - Experience of more than 2 years in related field will be considered for senior position. - Fresh graduates are encouraged to apply. - Indicates degree’s final year project abstract in the resume | 2200 – 3100 2200 – 3100 5000 – 7500) |
Software developer | 5 | 5 | 3 | -Indigo pacific sdn bhd -haicorp technology sdn bhd -captain travel & tours sdn. Bhd. -micropos sdn bhd (570016-h) -opensys (m) bhd | - Work closely with System Analyst/ Project Lead to design, develop, test and implement software development project - Work within a team to deliver projects - Keep up to date on current and emerging software development technologies - Perform day to day operations and troubleshooting | Min 1-2 years of relevant experience - Fresh graduates are encouraged to apply - Diploma or Degree in Information Technology - Strong Programming skills in Java/J2EE, Servlet, and Javascript - Proficiency in Windows Operating Systems - Strong Programming skills in Java | 2500 – 5000 Depends on Experience 3000 – 6000 |
System analyst | 1 | 1 | 4 | - asiapac Distribution Pte Ltd - Felda Holdings Bhd - Integrated Health Information Systems - tricklestar - QR Retail Automation (Asia) Sdn Bhd | To be involved in design, coding, testing and deployment of modern information system. - Might have opportunity to work with oversea.(depending on the project). - Provide support and troubleshooting for internal ASP.Net applications. | Degree/Diploma in Computer Science, Information Technology or its equivalent. - Must be proficient with ASP.NET, Visual C #, and HTML - Good knowledge in working on SQL Server& sharepoint. - Minimum 2-3 years’ relevant experience in ASP.NET development. | 3500 – 6500 (1 Month Guranteed + Var) 5000 – 8000 |
From our analysis the 3 main jobs that related to software engineering is software engineer,software developer and system analyst.from the job requirement,we can see that many of the company wanted to have an experience worker instead of fresh graduates.The average salary range for these job are from RM3000 to RM8000. To apply for most of this job, a programming skills are required.
07 June 2011
Task 2 - Module 2 - Software Process
- Method Use To Study : Do classifications notes , need extra reading from other source and do group discussion.
- Topic Should Be Added: Some part that we can drop are like CBSD,AOSD, UML and so on because we have learned before.
- Suggestion About another Teaching Technique: Seperate some sub topic to a few group. Every group need to do some presentation to other students.
- Lesson Learned From This Module:
03 June 2011
Task 2 - Module 1 - Intro SE
Module 1 : Introduction to Software Engineering
- Method Use To Study : Do classifications notes & extra reading(For more Example)
- Topic Should Be Added: The History behind Hooker's law and Polya suggestion.
- Suggestion About another Teaching Technique: Ask student To give idea for future software.
- Lesson Learned From This Module:
- Software Definitions:
-data structures that enable the programs to adequately manipulate information
-documentation that describes the operation and use of the programs.
-Examples: Microsoft words,Adobe dreamweaver,phython,visual basic
2. Software Applications Domain Matrix:
DOMAIN System software | CHARACTERISTICS - designed to operate computer hardware. | EXAMPLE -windows -Linux -Mac OS X -Ubuntu -Unix |
Application software | -interacts with the users -interacts with the hardware -help users to perform tasks | -point of sale (pos) -entertainment software ·arcade games ·mobile games -educational software ·learning software -media development software ·animation software |
Engineering/scientific software | -collection of computer programs -provide instructions to the computer | - -sas(stastical analysis software) -diagnosis sotware |
Embedded software | -software that combine together to control any electronic or electrical appliances such as telephone,toys and airplanes to peform any tasks asked by the users. | -software to control robot’s movement such or robotics control software and asimo -software to control the timeline of the digital watch |
Web apps | -application that is accessed using the network either internet or intranet | -student portal -uniten online registration system -ticket reservation system |
Artifcial intelegennce sotware | -programs or software that combines to perform any of the instructions -very complicated -combination of aspects such as logic,philosophy and behaviour | -kynogon(software that use in the video games). -asimo |
Production line software | -creating similar software system from a shared set of software by referring to the software engineering methods -have many functions -can peform any tasks | -ms word -ms power point -ms excel -ms access -ms outlook |
3. Software Engineering Definitions:
-The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software
4. Layer In Software Engineering:
Polya suggests:
i.Understand the problem (communication and modeling).
ii.Plan a solution (planning and design).
iii.Carry out the plan (construction and deployment).
iv.Examine the result for accuracy (testing and quality assurance).
Hooker’s General SE Principles
i.The Reason It All Exists
ii.KISS (Keep It Simple, Stupid!)
iii.Maintain the Vision
iv.What You Produce, Others Will Consume
v.Be Open to the Future
vi.Plan Ahead for Reuse
vii.Think!
6. Software Myths:
- erroneous beliefs about software and the process that is used to build it.
-Examples:
6. Software Myths:
- erroneous beliefs about software and the process that is used to build it.
-Examples:
- Management myths
- Customer myths
- Practitioner myths
29 May 2011
Assignment 1
Task 1: Group members Profile
ID Number IS 084506
Age 20
Course Bachelor Of Information Technology Major In Information System
Semesters Year 2 Semester 2
Name: Mohamad Nasruddin Bin Abdullah
ID Number: SW084972Age: 21
Course: Bachelor of Computer Science Major in Software Engineering
Semesters: Year 2 Semester 1
