Q2.Agile Model Pros and ConsAdvantages In iterative model we can only create a high-level design of the application before we actually begin to build the product and define the design solution for the entire product. Building and improving the product step by step. can get the reliable user feedback Less time is spent on documenting and more time is given for designing. Disadvantages Each phase of an iteration is rigid with no overlaps Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle
Q3.An application has the following:10 low external inputs, 12 high external outputs, 20 low internal logical files, 15 high external interface files, 12 average external inquiries and a value adjustment factor of 1.10 . What is the unadjusted and adjusted function point count ?Agile model pros Is a very realistic approach to software development Promotes teamwork and cross training. Functionality can be developed rapidly anddemonstrated. Resource requirements are minimum. Suitable for fixed or changing requirements Delivers early partial workingsolutions. Good model for environments that change steadily. Minimal rules, documentation easily employed. Enables concurrent development and delivery within an overall planned context. Little or no planning required Easy to manage Gives flexibility to developers Cons Not suitable for handling complex dependencies. More risk of sustainability, maintainability and extensibility. An overall plan, an agile leader and agile PM practice is a must without which it will not work. Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines. Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction. There is very high individual dependency, since there is minimum documentation generated. Transfer of technology to new team members may be quite challenging due to lack of documentation
Q4.What is a process model ? Describe the process model that you would choose to manufacture a car. Explain giving suitable reasons.Unadjusted function point counts may be calculated using as: UFP = ΣΣ Z ij w ij i = 1 J = 1 FP = 10 x 3 + 12 x 7 + 20 x 7 + 15 + 10 + 12 x 4 = 30 + 84 +140 + 150 + 48 = 452 = UFP x CAF = 452 x 1.10 = 497.2.
Q5 What is requirements elicitation? Explain various activities performed in it with watch system that facilitates to set time and alarm as an example?A structured set of activities required to develop a software system. • Many different software processes but all involve: •Specification – defining what the system should do; Design and implementation – defining the organization of the system and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing customer needs. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. • Process descriptions may also include: •Products, which are the outcomes of a process activity; Roles, which reflect the responsibilities of the people involved in the process; Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.
Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive software development. It can be successful only through an effective customer-developer partnership. It is needed to know what the users really need. There are a number of requirements elicitation methods. Few of them are listed below – 1. Interviews 2. Brainstorming Sessions 3. Facilitated Application Specification Technique (FAST) 4. Quality Function Deployment (QFD) 5. Use Case Approach The success of an elicitation technique used depends on the maturity of the analyst, developers, users and the customer involved. 1. Interviews: Objective of conducting an interview is to understand the customer’s expectations from the software. It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. Interviews maybe be open ended or structured. 1. In open ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem. 2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview. 2. Brainstorming Sessions: It is a group technique It is intended to generate lots of new ideas hence providing a platform to share views A highly trained facilitator is required to handle group bias and group conflicts. Every idea is documented so that everyone can see it. Finally a document is prepared which consists of the list of requirements and their priority if possible. 3. Facilitated Application Specification Technique: It’s objective is to bridge the expectation gap – difference between what the developers think they are supposed to build and what customers think they are going to get. A team oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are- 1. Part of the environment that surrounds the system 2. Produced by the system 3. Used by the system Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting. 4. Quality Function Deployment: In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which are valuable to the customer. 3 types of requirements are identified – Normal requirements – In this the objective and goals of the proposed software are discussed with the customer. Example – normal requirements for a result management system may be entry of marks, calculation of results etc Expected requirements – These requirements are so obvious that the customer need not explicitly state them. Example – protection from unauthorised access. Exciting requirements – It includes features that are beyond customer’s expectations and prove to be very satisfying when present. Example – when an unauthorised access is detected, it should backup and shutdown all processes. The major steps involved in this procedure are – 1. Identify all the stakeholders, eg. Users, developers, customers etc 2. List out all requirements from customer. 3. A value indicating degree of importance is assigned to each requirement. 4. In the end the final list of requirements is categorised as – It is possible to achieve It should be deferred and the reason for it It is impossible to achieve and should be dropped off 5. Use Case Approach: This technique combines text and pictures to provide a better understanding of the requirements. The use cases describe the ‘what’, of a system and not ‘how’. Hence they only give a functional view of the system. The components of the use case deign includes three major things – Actor, Use cases, use case diagram. 1. Actor – It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors. Primary actors – It requires assistance from the system to achieve a goal. Secondary actor – It is an actor from which the system needs assistance. 2. Use cases – They describe the sequence of interactions between actors and the system. They capture who(actors) do what(interaction) with the system. A complete set of use cases specifies all possible ways to use the system. 3. Use case diagram – A use case diiagram graphically represents what happens when an actor interacts with a system. It captures the functional aspect of the system. A stick figure is used to represent an actor. An oval is used to represent a use case. A line is used to represent a relationship between an actor and a use case.
0 Comments