UNITENIANS

Tweet

Tweet

Basically Chapter 4 explains design creates the representation or model of the software. Different than the analysis model , design model provides details such as software architecture , data structures , interfaces and components that are necessary to implement the system. Thus it is important because model design can assessed for quality and improvement before code , test and more users gets involved.

Apart from that , a good characterictis of a design must be :-

• implementation of all the expilcit requirements contained in the analysis model and it must accomodate all the implicit requirements desired by the customer
• must be readable , understandable guide for those who generate code and for those who test and subsequently support the software
• must provide a complete picture of the software , addressing the data , functional and behavioral domains from an implementation perspective

And design principles must include :-

• should not suffer from 'tunnel vision'
• should be traceable to the analysis model
• should not reinvent the wheel
• should minimize the intellectual distance between software and problem
• should exhibit uniformly and integration
• should be structure to accomodate changes
• should be structure to degrade gently
• design is not a coding ,coding is not design
• design should be assessed for quality as it is being created
• should be reviewed to minimize conceptual (semantic) errors

In model design , design concepts should cover :-

1. Abstraction that is divided into Procedural abstraction and Data abstractions
2. Architecture that basically describe the overall structure of the software
3. Patterns
4. Separations of concerns , its a rule of thumb to define how modules should be separated
5. Modularity , to divide into components
6. Information hiding
7. Functional Independence
8. Refinement
9. Aspects
10. Refactoring
11. OO Design concepts
12. Design classes

Tweet

Question 1 :
Method (s) best used to study the module.
There are several ways to study this module and there a ton of technique that can be apply to remember all the facts and keywords in chapter 1 such as :

• Mind map

This technique are the most popular to the student and all practitioner around the world. Mind map is proven effective by many successfull people in the world and has helped many in their daily such as work , studies and etc.

Second, we can also practise the use of questionnaire. By using the principle of 5W question

• what
• where
• who
• why
• when
• how

Question 4:
To summarize Chapter 8, this chapter mainly about on how software evolve when the project is been held.

Tweet

Practitioner’s myths:

• 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 code, the longer it’ll 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.

Disscussion : If we were to start writing the codes before proper design and planning, the project would take longer to complete. This is because the programmers are building codes blindly. Having only a rough idea of how it is supposed to work and in the end, in order to amend these mistakes, much more time would be taken.

• Myth: Until i get the program running. I have no way of assessing its quality.

• Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.

Disscussion : Quality assessment can be done throughout project development from the moment the project is accepted by having software reviews. By reviewing software, whole software can be tested for its functionality and quality in one go.

• Myth: The only deliverable work product for a successful project is the working program.

• Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.

Disscussion : When creating software, each stage of development should be documented and should be delivered to the client to provide assurance of project development as well as to give them an idea of how the project is going so far. Apart from that, each aspect of the software is documented in order to provide detailed description of how the software works.


Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet

Customer myths:

• 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 requirement 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.

Disscussion : Requirements determine the desired outcome of a project because in the developer have to satisfy customer demands and as people say 'the customer is always right'. In the case of software engineering, the developer must meed customer demands and make necessary changes to comply with the customer's requirement. Continuous communication helps make this happen.

• Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

• Reality: It is true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement change 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.

Disscussion : When a project is started, design and planning is done in order to reach a goal which is to meet the client's requirements. When these requirements change, the goal is changed as well and several unnecessary changes have to be made to the software down to the programming level and this would waste costs such as resources and time.

Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet

Software Myths :

Management myths :

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

• Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it adaptable? Is it streamlined to improve time to deliver while still maintaining a focus on quality? In many cases. The answer to all of these questions is no.

• Disscussion :Software engineering is an ever changing field that is always up to date with new technologies and resources. The book that we have is sufficient to get us started but further research is required in order to find the best and most up-to-date way of engineering a software.

• Myth : If we get behind schedule, we can add more programmers and catch up
  

• Reality : Brooks said “Adding people to a late software project makes it later.” As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development. People can be added but only in a planned and well-coordinated manner.

• Disscussion : More people means more minds at work in order to develop a software. The fact that these new people have not been around since the beginning of the project means that they are practically only seeing it for the first time and need to be brought to the same page as the developing team's current progress. This takes a lot of time and is not affordable at a late software project.

• Myth : If I decide to outsource the software project to a third party. I can just relax and let that firm build it.

• Reality : In an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.

• Disscussion : When an organization outsources a project, they need to know exactly what they want from it as in the product of the software. The requirements gathered at the beginning of a project might change as software is developed and we also have to consider the fact that the developing firm makes a mistake in software development that conflicts with the desired outcome of the client.

Discussion done by : Talib, Lim Jia Hui, Gary Jordan, Shilpesh.

Tweet