DEPARTMENT OF COMPUTER SCIENCE, FUTA CSC 409: sOFTWARE ENGINEERING TEST ANSWER A
ID: 3710117 • Letter: D
Question
DEPARTMENT OF COMPUTER SCIENCE, FUTA CSC 409: sOFTWARE ENGINEERING TEST ANSWER ALL QUESTIONS. TIME ALLOWED 1HOUR. 05/05/2014 1. What is the aim of Software Engineering? Software has to be developed for Nigeria Airways Reservation System. Use Cases to capture the following reservation III. Pay for reservation. IV. Modify Reservation. V. View flight 2. List all the characteristics of a good SRS. When is SRS said to be complete? product to be developed has been estimated to be 22000 LOC. Predict the details of the system for the passengers. I. Reserve seat. II. Cancel Schedule .VI. Print boarding pass. 3. Compare Walston &Felix; model with SEL Model. The size of a software manpower cost (effort) and duration in (months) by Walston-Felix Model 4. Three projects of size (40Loc, 280Loc, 70oto?) are to be developed, COCOMO model: Calculate the effort, development time, average using staff size, and productivity of the three projects. Use the table below: Project db 2.4 3.0 3.6 1.05 1.12 1.20 anic Semidetached Embedded 5. What is the effect of Cohesion and Coupling on Software design 6. What is Software Process? Why is it difficult to improve it? How are 7. Describe the role of management in software development. Discuss the 8. List the phases of Waterfall Model. Compare Waterfall model with Spiral 9. What is Requirements Engineering (RE)? List the steps in RE modularity? software myths affecting the software process? selection process parameters for a life cycle model. model 10.What is Expectation Gap?Explanation / Answer
1)Answer:
Software engineering's aim is to reflect the human fluidity of seeing things in new ways with a fluidity in changing software structure. We want software to keep up with our imagination.
According to definition of software engineering The main aim of software engineering is
->fault free
->Delivered on time
->Delivered withing budget
->satisfies users needs
Software engineering aims at clarity and fluidity because these are what softwareessentially and distinctively is about. A bit is precisely 0 or 1, and easily changeable between them. Software is clarity and fluidity.
2)Answer:
Characteristics of a Good SRS:
Complete
A complete requirements specification must precisely define all the real world situations that will be encountered and the capability’s responses to them. It must not include situations that will not be encountered or unnecessary capability features.
2. Consistent
System functions and performance level must be compatible and the required quality features (reliability, safety, security, etc.) must not contradict the utility of the system. For example, the only aircraft that is totally safe is one that cannot be started, contains no fuel or other liquids, and is securely tied down.
3. Correct
The specification must define the desired capability’s real world operational environment, its interface to that environment and its interaction with that environment. It is the real world aspect of requirements that is the major source of difficulty in achieving specification correctness. The real world environment is not well known for new applications and for mature applications the real world keeps changing. The Y2K problem with the transition from the year 1999 to the year 2000 is an example of the real world moving beyond an application’s specified requirements.
4. Modifiable
Related concerns must be grouped together and unrelated concerns must be separated. Requirements document must have a logical structure to be modifiable.
5. Ranked
Ranking specification statements according to stability and/or importance is established in the requirements document’s organization and structure. The larger and more complex the problem addressed by the requirements specification, the more difficult the task is to design a document that aids rather than inhibits understanding.
6. Testable
A requirement specification must be stated in such as manner that one can test it against pass/fail or quantitative assessment criteria, all derived from the specification itself and/or referenced information. Requiring that a system must be “easy” to use is subjective and therefore is not testable.
7. Traceable
Each requirement stated within the SRS document must be uniquely identified to achieve traceability. Uniqueness is facilitated by the use of a consistent and logical scheme for assigning identification to each specification statement within the requirements document.
8. Unambiguous
A statement of a requirement is unambiguous if it can only be interpreted one way. This perhaps, is the most difficult attribute to achieve using natural language. The use of weak phrases or poor sentence structure will open the specification statement to misunderstandings.
9. Valid
To validate a requirements specification all the project participants, managers, engineers and customer representatives, must be able to understand, analyze and accept or approve it. This is the primary reason that most specifications are expressed in natural language.
10. Verifiable
In order to be verifiable, requirement specifications at one level of abstraction must be consistent with those at another level of abstraction. Most, if not all, of these attributes are subjective and a conclusive assessment of the quality of a requirements specification requires review and analysis by technical and operational experts in the domain addressed by the requirements.
6)Answer:
Software process:
A software process (also knows as software methodology) is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system.
Any software process must include the following four activities:
9)Answer:
Requirements engineering:
Requirements engineering is the process of conforming engineering designs to a set of core software requirements. This is critically important for creating accurate results in software engineering.
Requirements engineering is also known as requirements analysis
In requirements engineering, engineers look at a set of data pertaining to the goals and objectives of the software: how it will work and what are the qualities of the properties it must have to provide the results needed. Engineers then work forward from these data to look at specific coding solutions that support these results. Elements of requirements engineering include:
It is important to point out that a major part of requirements engineering has to do with the stakeholders or parties involved in the process. Typically, developers from a software company tailor the software requirements according to the needs of the client. That means that many stages of requirements engineering happen during the communications between the client and the software company.
IT experts have pointed out how requirements engineering remains a significant challenge for companies, partly because of the ambiguous nature of software development, the challenge of getting accurate requirements from a client, and the ongoing process of matching internal processes at a development company to the goals and objectives of an outside client. In other words, requirements engineering attempts to bridge that divide between what the client and what the developers are thinking, and to create a solid, consistent framework for the actual construction of sophisticated software products.
Steps of Requirement Engineering:
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.