CSEB233: 2011

Wednesday 20 July 2011

Task 2 : Module 8

After the end of chapter 8 we discovered the best way to study module 8 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 8 : Software Evolution

Saturday 16 July 2011

Task 2 : Module 7

After the end of chapter 7 we discovered the best way to study module 7 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 7 : Software Quality Management

Sunday 10 July 2011

Task 2 : Module 6

After the end of chapter 6 we discovered the best way to study module 6 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 6 : Software Verification And Validation

Friday 1 July 2011

Task 2 : Module 5

After the end of chapter 5 we discovered the best way to study module 5 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 5 : Software Implementation/Coding

Wednesday 22 June 2011

Task 2 : Module 4

After the end of chapter 4 we discovered the best way to study module 4 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 4 : Software Design

Wednesday 15 June 2011

Task 2: Module 3

After the end of chapter 3 we discovered the best way to study module that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 3: Requirement Engineering

Saturday 11 June 2011

Task 4

Management myths. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth. if that belief will lessen the pressure (even temporarily).

Myth:We already have the book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know?

Reality: The book standards may very well exist, but think about it. Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time to delivery while still maintaining a focus on quality? . As time changes, the procedure and standards for building a certain software also changes. with technology prowess that we have now we can predict that in the future another evolution of software methodology would occur and people and/or companies have to adapt to the newest technology to compete with other companies and there is no such thing as a book that has a complete, and adaptable standards or procedure for building software.

Customer myths. A customer who requests a 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 lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer.

Myth: A general statement of objectives is sufficient to begin writing programs we can fill in the details later.

Reality: Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is recipe for disaster. Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous communication between customer and developer.

Practitioner’s myths. Myth that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard.

Myth: Once we write the program and get it to work, our job is done.

Reality: Someone once said that the sooner you begin writing codes, the longer it will take you to get done. Industry data 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.As a practitioner/developer, developing software lies heavily on the customer, what they want.It is not unusual that a completed and running program could be rejected there and then by the customer for not fulfilling/achieving what they had hoped for.

Reference: “Software Engineering A Practitioner’s Approach 6edition & 7edition” Book(s).

Friday 10 June 2011

Task 3

Software Engineering (SE) is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software.

Software Developer is a person concerned with facets of the software development process. They can be involved in aspects wider than design and coding, a somewhat broader scope of computer programming or a specialty of project managing including some aspects of software product management. This person may contribute to the overview of the project on the application level rather than component level or individual programming tasks. Software developers are often still guided by lead programmers but also encompasses the class of freelance software developers.

Systems Analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements. They will be familiar with multiple variety of programming languages, operating systems, and computer hardware platforms. Because they often write user requests into technical specifications, the systems analysts are the liaisons between vendors and information technology professionals. They may be responsible for developing cost analysis, design considerations, and implementation time-lines.

System Consultant provides presales technical and consulting support for Information Management Technologies, Inc.. Working with the account manager, the System Consultant develops project strategies to ensure successful delivery. The System Consultant forms partnerships with the Client’s technical and operational personnel. In many engagements, the Project Manager and System Consultant roles are fulfilled by one person.

CONCLUSION

From the table above we can see that there is a lot of vacant involving Software Engineering profession. So we can conclude that this profession has a bright future for us. As a student, we need to widen our knowledge and enhance our skill to make ourselves valuable to the market. As we can see from the table above, the company has bold out the requirement needed for one to apply the job. As the technology evolve rapidly, the requirement will be updated to the current system and it will be more specific than rather just know how to use software to qualify us as an applicant. The number of experienced needed will be increased to let the applicant that apply matured experienced in the profession. As for us, fresh graduates will have to compete with the senior to fill the position. This is where the skills matters, we have to prepare ourselves with some skills to let ourselves shine.

Tuesday 7 June 2011

Task 2: Module 2

After the end of chapter 2 we discovered the best way to study module 2 that is through the making of mind map. Our group have decided to make one. Below is the mind map of Module 2 : Software Process

Thursday 2 June 2011

Task 2: Module 1

After the end of chapter 1 we discovered the best way to study module 1 that is through the making of mind map. our group have decided to make one as suggested from friends taking this subject last semester. Below is the mind map of module 1 : Fundamental of Software Engineering.