Sponsored Links

Results 1 to 1 of 1

Thread: cs615 assignment no 2 idea solution

  1. #1
    Administrator Xpert's Avatar
    Join Date
    May 2010

    14 cs615 assignment no 2 idea solution

    Sponsored Links1

    Download the attachment
    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?

    Sponsored Links

    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

    Ψ Standish Group listed "Lack of User Input" as most common factor of
    challenged projects.
    Ψ 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
    Ψ 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.
    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:
    • Information Expert
    • Creator
    • Controller
    • Low Coupling
    • High Cohesion
    • Polymorphism
    • Pure Fabrication
    • Indirection
    • Protected Variations

    l This approach to understanding and using design principles is based on patterns of
    assigning responsibilities.
    l The GRASP patterns are a learning aid to help one understand essential object
    design, and apply design reasoning in a methodical, rational, explainable way.
    l 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.
    l Doing:
    l Doing something itself, such as creating an object or doing a calculation
    l Initiating action in other objects
    l Controlling and coordinating activities in other objects.
    l Knowing:
    l Knowing about private encapsulated data
    l Knowing about related objects
    l Knowing about things it can derive or calculate
    l Interaction diagrams show choices in assigning responsibilities to objects.
    l GRASP patterns guide choices in where to assign responsibilities.
    l GRASP patterns are a codification of widely used basic principles.
    l Assign a responsibility to the information expert – the class that has the
    information necessary to fulfill the responsibility.
    l What is a general principle of assigning responsibilities to objects?
    l Who should be responsible for knowing/doing …?
    l Domain model (domain expert, domain analysis) to design model
    (software classes).
    l 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
    Creational Design Patterns
    Singleton Design Pattern
    Visitor Design Pattern
    Strategy Pattern
    Command Pattern
    Proxy Design Pattern
    Singleton Design PatternThe 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
    ThreadLocal implementation for better singleton implementation in a multithreaded
    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:
    1. If an object, such as a large image, takes a long time to load.
    2. If the object is on a remote machine and loading it over the network may be slow,
    especially during peak network load periods.
    3. If the object has limited access rights, the proxy can validate the accesspermissions for
    that user.
    The Visitor Design Pattern The Visitor pattern turns the tables on our objectoriented
    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
    TheStrategyPattern 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
    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
    Attached Files Attached Files

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 0
    Last Post: 04-06-2012, 07:45 PM
  2. Replies: 0
    Last Post: 06-21-2011, 05:26 PM
  3. Replies: 0
    Last Post: 06-10-2011, 05:00 AM
  4. Replies: 0
    Last Post: 06-02-2011, 06:48 PM
  5. Replies: 2
    Last Post: 05-01-2011, 04:55 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
-: Vuhelp Disclaimer :-
None of the files shown here are hosted or transmitted by this server. The links are provided solely by this site's users. The administrator's or staff of Vuhelp.net cannot be held responsible for what its users post, or any other actions of its users. You may not use this site to distribute or download any material when you do not have the legal rights to do so. It is your own responsibility to adhere to these terms. If you have any doubts about legality of content or you have any suspicions, feel free to contact us.
Online Education | JhelumSoft | Jobs