
- •11. Why do we need documentation?
- •12. What is Subversion?
- •13. What is dd? Why do we need it?
- •14. What is Use-Case? Why do we need it?
- •15.(Context: Design patterns) Describe Builder pattern. Give an example
- •16. The importance of software design can be summarized in a single word. What is it? Explain
- •17. Why each requirement has to be specified in detail?
- •5 Major Steps in Requirements
- •18. (Context: Design concepts) Explain Information hiding
- •19. What is ftr? Why do we need it?
- •20. What is coupling?
- •21. In terms of design, what is interface?
- •11. What is the real test of a good requirements document?
- •12.(Context: Source control) Describe branching/merging/ tagging.
- •13. What is srs? Why do we need it?
- •14. What is Feature? Why do we need it?
- •15. (Context: Design patterns) Describe Singleton pattern. Give an example
- •16. What are the characteristics of a good design?
- •17. What are some of the responsibilities of project manager?
- •18. (Context: Design concepts) Explain Refactoring
- •19. Furps should be a target for all software. What is it?
- •20. Describe the three main barriers faced during the elicitation of requirements
- •21. What is cohesion?
16. The importance of software design can be summarized in a single word. What is it? Explain
WE can write a lot of word, but by my opinion main of this is words efficiency, all our project must be efficiency as good as possible! Without efficiency, project can not be more useful, projects can be easy, but useful, this is good developed project.
17. Why each requirement has to be specified in detail?
The initial step in software development, The concept is explored and refined, and the client’s requirements are elicited. A singular documented need of what a particular product or service should be or perform (a necessary attribute, capability, characteristic, or quality of a system).
Typically, only experienced employees are assigned this important job, Most errors occur in upstream activities (i.e. Requirements and Architecture phases), The cost of fixing a bug in later phases is much more expensive.
5 Major Steps in Requirements
Analysis: Understanding Problem Domain, Modeling, Context Model, Dictionary of Terms: customer jargon vs. technical jargon, SRS-1 dictionary, Two approaches to analysis
Elicitation: 3 main barriers:
Communication
Changes
Completeness
Triage
Specification: Basis for contracts
Typically, handed over to design team
Cost estimation & tracking
Testing
Thus, requirements must be:
Unambiguous & complete
Traceable
Feasible
Testable
Maintainable
Verification and Validation
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. It is an early stage in the more general activity of requirements engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements
18. (Context: Design concepts) Explain Information hiding
The principle of information hiding suggests that modules be characterized by design decisions that each hides from all others. The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later, during software maintenance.
19. What is ftr? Why do we need it?
A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives: - uncover errors in function, logic or implementation of the software. - verify that the software meets its requirements. - ensure that the software has been developed according to the standards. - achieve uniform software. - make projects manageable.
Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.
20. What is coupling?
Coupling measures the strength of all relationships between functional units
The degree to which components depend on one another. There are two types of coupling, "tight" and "loose". Loose coupling is desirable for good software engineering but tight coupling may be necessary for maximum performance. Coupling is increased when the data exchanged between components becomes larger or more complex.