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

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

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

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

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

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

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).