Examples of Software Projects That Would Be Amenable to the Prototyping Model - Assignment Example

Exam Questions and Answers May 17, Question Consider the (7) software categories (or types) presented in Section 1.2, can the same approachfor software engineering be applied to each of them? Answer: Pressman (2010, p. 7-8) has identified seven broad categories of software namely, system software, application software, engineering and scientific software, Embedded software, Product-line software, Web applications and Artificial intelligence software. Each category has a unique function, with different designs, tools and method of programming. The software process framework encompasses of five activities and these are communication, planning, modeling, construction and deployment (p. 15). Since each software category is unique, each has unique customer requirements and adopting a different approach for the design and development is essential though some common elements can exist. As an example, legacy applications are software designed and implemented in the previous decade and have limited functionality. At the same time, web applications use the latest programming techniques, gather inputs from a variety of sources and offer many new functionalities, features and modules (p. 16-17). Hence, the same approach of software engineering cannot be applied to them. Question #2 Provide (3) examples of software projects that would be amenable to the prototyping model discussed in Chapter 2. Be specific. Answer: Prototyping model is a part of the prescriptive process model and is a part of the evolutionary process model. In prototyping, the customer defines a general set of objectives for functions and features. The developer then uses these requirements as the basis, identifies the requirements and then creates a prototype model for the software that is further refined until the final product is ready (p. 43-44). The prototype model is used to develop applications used by a organizations in different sectors namely, banking, insurance, manufacturing and retail. As an example, banking applications have requirements such as registering the customer, assigning an account number for each customer and tracking their account related activities. On the other hand, a manufacturing firm produces a small range of products with a fixed number of parts. In this case, the prototype model must allow the organization to track each part, assist the marketing department in sales, aid the accounts department to carry out billing and so on (p. 45). Question #3 Re-read “The Manifesto for Agile Software Development” at the beginning of Chapter 3. What are some situations in which one or more of the four “values” could get a software team into trouble? Answer: The Manifesto for Agile Development has the objective of finding better ways of developing software and it is based on four values (p. 65). However, some situations can arise that can vitiate the development procedure and create trouble for the software team. These possible situations are briefly discussed as follows. Individuals and interactions over processes and tools: Process and tools specify protocols and methods in which they should be used. If team members decide to ignore these protocols, then the resulting software would lack standardization. Working software over comprehensive documentation: Documentation provides a blue print and road map for the development process and any changes in the product must be documented. Otherwise, it is difficult to track changes. Customer collaboration over contract negotiation: Collaboration with customers and their involvement aids in achieving greater acceptance while contracts provide the legal framework. If contracts are ignored then payment and scope related issues can occur. Responding to change over following a plan: Agile development responds to quick demands for change. However, frequent change requirements increase the quantum of work. Question #4 Why do we say that the requirements model represents a snapshot of a system in time? Answer: "The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements engineering" (p. 120). The process of requirements gathering has different stages namely, Inception, Elicitation, Elaboration, Negotiation and Specification. The problem that can arise is when multiple stakeholders give their viewpoint and in some cases, these viewpoints are contradictory and come up late in the project development cycle. In the first iteration, the product follows the requirements elicited from the stakeholders. Subsequent iterations need to follow the previous requirement so that the software is refined and at each stage, it represents a snapshot of the system at that time. These snapshots must indicate the manner in which the software evolved along an accepted path. If requirements change drastically at any stage, the snapshot indicates an uneven and often unrecognizable snapshot. Question #5 Write a template-based use case for the SafeHome home management system described informally in the sidebar following Section 6.5.4. Answer: The use case for the SafeHome home management system is described as follows (p. 179-180). Title: Manage the requirements modeling of SafeHome Primary Actors: members of the SafeHome software engineering team Goal in Context: Use the home management interface on a PC or an Internet connection to control electronic devices that have wireless interface controllers. Scope: System should allow operating specific lights, control appliances, set heating and air conditioning systems as per requirements, control all audio visual devices and set the house for various situations such as home, away, overnight travel and extended travel. Precondition: Availability of control through Internet Success Guarantees: Extensive interfacing of hardware and software elements Trigger: Invoke operation accessFloorplan() Attributes: optionsPanel situationPanel floorplan deviceIcons devicePanels Operations: displayControl(), selectControl(), displaySituation(), selectsituation(), accessFloorplan(), selectDeviceIcon(), displayDevicePanel(), accessDevicePanel() Class: HomeManagementInterface Responsibility Collaborator displayControl() OptionsPanel (class) selectControl() OptionsPanel (class) displaySituation() SituationPanel (class) selectSituation() SituationPanel (class) accessFloorplan() FloorPlan (class) Question #6 Provide (5) GOOD examples from other fields of study or disciplines that illustrate the problems associated with a reactive risk management strategy. Answer: Reactive risk management strategy indicates that organizations do not have a fixed vulnerability assessment and risk management strategy but manage the risk event when it occurs (p. 744-746). This type of strategy is used when an organization is poorly structured or when a large variety of risks can occur and it is not possible to have a plan to manage all of them. Examples of reactive risk management include restaurants that face the risk of patrons choking on their food or spilling hot beverage on their laps. Another example is of having a spare tire when one goes on a journey, even though the car has four tires and there is a risk that more than one tires is punctured. Manufacturers sending consignments by truck run the risk of the truck getting involved in an accident and no one considers sending a spare truck to follow the original vehicle. Manufacturing industries run the risk of supply disruptions when their key machine breaks down and procuring an alternative machine is very expensive and not considered. Another example is seen in the casting industry when the molten metal is poured into the cast and if the cast product does not meet the specifications, it is reworked or scrapped. Question #7 The relationship between people and time is highly non-linear. Using Putnams software equation (described in Section 27.2.2), develop a table that relates number of people to project duration for a software project requiring 50,000 LOC and 15 person-years of effort (the productivity parameter is 5000 and B = 0.37). Assume that the software must be delivered in 24 months, plus or minus 12 months. Answer: The Putnam-Norden-Rayleigh (PNR) Curve provides an indication of the relationship between effort applied and delivery time for a software project (p. 726-727). The equation is: L = P x E1/3 x t4/3 or E = L3/ P3 t3 Level of effort E = 50000 LOC Nominal delivery time td = 24 months plus minus 12 months E = Development effort in person months P = Productivity parameter at 5000 t = project duration or nominal delivery time in calendar months given as 24 months plus minus 12 months Using the above values, the following table is derived: E L3 P3 t3 0.072338 250*1012 125*109 13824 0.578704 250*1012 125*109 1728 0.021433 250*1012 125*109 46656 Question #8 It seems odd that cost and schedule estimates are developed during software project planning – before detailed software requirements analysis or design has been conducted. Why is this done? Are there circumstances when it should not be? Answer: Cost and schedule estimates are initially calculated to obtain an approximate budget and cost that the customer will have to bear (p. 691). During projects where contracts and tender methods are used, the software vendor reviews the tender documents and estimates the overall costs, adds the profits and other incidental costs and places the bid. The customer then takes a decision on the bids and awards the contract. Detailed software requirements are an extended process that may extend to a few weeks since many stakeholders such as department heads list their requirements. However, this exercise is to gather the functional requirement of the project. This procedure of estimating the costs before the requirements gathering are done is used when the customer invites a vendor to make a preliminary assessment for a new application or to upgrade an existing system. Question #9 Based on information presented in Chapter 24 and your own experience with your final projects, develop “ten commandments” for empowering software engineers. That is to say, make a list of 10 guidelines that will lead to software people who work to their full potential. Answer: Ten guidelines for software engineers are listed as follows (p. 652-667): 1. Develop list of clarification issues with customers 2. Meet with stakeholders to address clarification issues. 3. Jointly develop a statement of scope and review the statement of scope with all concerned 4. It is important to Melding the Product and the Process with customers requirements 5. It is important to start on the right foot and maintain the momentum 6. Progress needs to be tracked regularly and analyzed to find the shortcomings and methods to improve them 7. It is important to understand reasons for developing the software, create a detailed work breakdown structure and assign responsibilities along with a schedule 8. Technical details, coding, databases and the interface are important but they are achieved only when other stakeholders are involved 9. Training is important to help the engineers to keep their skills updated 10. Other than technical skills, it is very essential to develop team working and communication skills and maintain an appropriate attire Question #10 From Chapter 17, why is highly-couple software so difficult to unit test? Answer: Coupling in software engineering refers to the extent of dependency and linkage that one module has on another. High coupling indicates a higher level of interdependency between the modules, shows increased coordination and high information flow occurs between the modules. In some instances, high coupling also signifies that one module depends on the internal operation of another module by accessing data and instructions. The very nature of such products indicates that it is difficult to carry out unit testing where each module is tested separately. Since the routines in highly coupled softwares depend on another module, it becomes difficult to trace errors and bugs and to find the reason or the line of code that raises errors. Other problems arise when an error is detected in the module and changes are done in another module. The impact of these changes must be understaood; otherwise, the changed code creates more errors (p. 458-459. References Pressman, Roger. Software Engineering: A Practitioner’s Approach, Seventh Edition. London: McGraw Hill, 2010 Read More