Solution:
Question # 1:
01 How Facilitated Application Specification Techniques (FAST) help in the requirement elicitation for software? Is requirement analysis and requirements elicitation is same thing?
Solution:
Effective software management plan much depends on the nature of the software itself, to be developed. The plan can only remain successful if all the scheduled activities are performed according to the timelines already decided. It has been observed that quite a high amount of projects both in developing and developed countries fail despite the organization wide process maturity. There are many factors that contribute in the successful and on time completion of the software but the most important of the phases is the requirement engineering in which requirement are to be fabricated and rectified again and again to suggest the most appropriate requirements. FAST (Facilitated Application Specification Technique) has emerged as a technology to help decrease the communication gap between the customer and the developer. The success of FAST session generally depends on the way the session is conducted by the facilitator
Requirement analysis
Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis is an important aspect of project management.
Requirements analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to finish.
Energy should be directed towards ensuring that the final system or product conforms to client needs rather than attempting to mold user expectations to fit the requirements.
Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people.
Requirements Elicitation
a) Standish Group listed "Lack of User Input" as most common factor of challenged projects.
b) Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development.1
c) Development teams have to take the initiative.
Requirements elicitation is concerned with where software requirements come from and how the software engineer can collect them. It is the first stage in building an understanding of the problem the software is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the development team and the customer. It is variously termed "requirements capture," "requirements discovery," and "requirements acquisition."
One of the fundamental tenets of good software engineering is that there is good communication between software users and software engineers. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the domain of the software users (and other stakeholders) and the technical world of the software engineer.
Question # 2:
Make comparative analysis between the GOF design pattern and GRASP design pattern with their pros and cons.
Solution:
GRASP stands for General Responsibility Assignment Software Patterns
There are several GRASP patterns. Some of them are simply good design principles, and one can argue whether they are really patterns. For example, High Cohesion and Low Coupling are two that are well known design principles and not really patterns.
The full set of GRASP patterns are:
1. Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Polymorphism
7. Pure Fabrication
8. Indirection
9. Protected Variations
I. This approach to understanding and using design principles is based on patterns of assigning responsibilities.
II. The GRASP patterns are a learning aid to help one understand essential object design, and apply design reasoning in a methodical, rational, explainable way.
III. After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requirements.
Doing:
a) Doing something itself, such as creating an object or doing a calculation
b) Initiating action in other objects
c) Controlling and coordinating activities in other objects.
Knowing:
a) Knowing about private encapsulated data
b) Knowing about related objects
c) Knowing about things it can derive or calculate
a) Interaction diagrams show choices in assigning responsibilities to objects.
b) GRASP patterns guide choices in where to assign responsibilities.
c) GRASP patterns are a codification of widely used basic principles.
d) Assign a responsibility to the information expert – the class that has the information necessary to fulfill the responsibility.
e) What is a general principle of assigning responsibilities to objects?
f) Who should be responsible for knowing/doing …?
g) Domain model (domain expert, domain analysis) to design model (software classes).
h) Any existing to any representative.
GOF design pattern
A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it.
There are many types of GOF design pattern we will discuss some of them
I. Creational Design Patterns
II. Singleton Design Pattern
III. Visitor Design Pattern
IV. Strategy Pattern
V. Command Pattern
VI. Proxy Design Pattern
Singleton Design Pattern: The Singleton pattern ensures that a class has only one instance. Provides a global point of access to that instance.
Constructor is 'PRIVATE'. This ensures that no other code in your application will be able to create an instance of this class, by using the constructor directly. Using a static method, which returns an object? Static variable, used for holding the created instance. If the instance is already there, the static method do not create a second one, instead returns the already created one. When multiple threads are introduced, you must protect the getInstance() method through synchronization. If the getInstance() method is not protected against synchronization, it is possible to return two different instances of the Singleton object. Refer to Double Checked Lock (DCL) programming pattern and Thread Local implementation for better singleton implementation in a multithreaded environment.
The Proxy Design Pattern the Proxy pattern is used when you need to represent an object that is complex or time consuming to create, by a simpler one. If creating an object is expensive in time or computer resources, Proxy allows you to postpone this creation until you need the actual object. A Proxy usually has the same methods as the object it represents, and once the object is loaded, it passes on the method calls from the Proxy to the actual object. There are several cases where a Proxy can be useful:
a) If an object, such as a large image, takes a long time to load.
b) If the object is on a remote machine and loading it over the network may be slow, especially during peak network load periods.
c) If the object has limited access rights, the proxy can validate the access permissions for that user.
The Visitor Design Pattern: The Visitor pattern turns the tables on our object-oriented model and creates an external class to act on data in other classes. This is useful when you have a polymorphic operation that cannot reside in the class hierarchy for some reason.. For example, the operation wasn't considered when the hierarchy was designed, or because it would clutter the interface of the classes unnecessarily.
The Strategy Pattern: The Strategy pattern is much like the State pattern in outline, but a little different in intent. The Strategy pattern consists of a number of related algorithms encapsulated in a driver class called the Context. Your client program can select one of these differing algorithms or in some cases the Context might select the best one for you. The intent is to make these algorithms interchangeable and provide a way to choose the most appropriate one. The difference between State and Strategy is that the user generally chooses which of several strategies to apply and that only one strategy at a time is likely to be instantiated and active within the Context class.
By contrast, as we have seen, it is possible that all of the different States will be active at once and switching may occur frequently between them. In addition, Strategy encapsulates several algorithms that do more or less the same thing, while State encapsulates related classes that each do something somewhat different. Finally, the concept of transition between different states is completely missing in the Strategy pattern.
The Command Pattern: The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific object. It encloses a request for a specific action inside an object and gives it a known public interface. It lets you give the client the ability to make requests without knowing anything about the actual action that will be performed, and allows you to change that action without affecting the client program in any way
