February 2011 Master of Computer Application (MCA) Semester 3 MC0071 Software Engineering 4 Credits (Book ID: B0808 &

p; B0809) Assignment Set 1 (60 Marks)

Answer all Questions Each question carries TEN marks

Book ID: B0808 1. Describe the concurrent development model in your own words. Ans: Concurrent Development Model The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states. For e.g.:, the engineering activity defined for the spiral model is accomplished by invoking the following tasks: Prototyping or analysis modeling, requirements specification, and design. Figure shows that it provides a schematic representation of one activity with the concurrent process model. The activity-analysis-may be in any one of the states noted at any given time. Similarly, other activities (e.g. Design or customer communication) can be represented in an analogous manner. All activities exist concurrently but reside in different states. For e.g., early in a project the customer communication activity has completed its first iteration and exists in the awaiting Changes State. The analysis activity (which existed in the none state while initial customer communication was completed) now makes a transition into the under development state. This generates the event analysis model correction, which will trigger the analysis activity from the done state into the awaiting Changes State.

Fig: One element of concurrent process model The concurrent process model is often used as the paradigm for the development of client/server applications. A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions a system dimension and component dimension. System level issues are addressed using three activities, design assembly, and use. The component dimension addressed with two-activity design and realization. Concurrency is achieved in two ways; (1) System and component activities occur simultaneously and can be modeled using the state oriented approach (2) a typical client server application is implemented with many components, each of which can be designed and realized concurrently.

The concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software-engineering activities to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities. Events generated within a given activity or at some other place in the activity network trigger transitions among the states of an activity.

2. Explain the following concepts with respect to Software Reliability: A) Software Reliability Metrics B) Programming for Reliability Ans: A) Software reliability Metrics Metrics which have been used for software reliability specification are shown in Figure below .The choice of which metric should be used depends on the type of system to which it applies and the requirements of the application domain. For some systems, it may be appropriate to use different reliability metrics for different sub-systems.

Fig: Reliability matrix In some cases, system users are most concerned about how often the system will fail, perhaps because there is a significant cost in restarting the system. In those cases, a metric based on a rate of failure occurrence (ROCOF) or the mean time to failure should be used. In other cases, it is essential that a system should always meet a request for service because there is some cost in failing to deliver the service. The number of failures in some time period is less important. In those cases, a metric based on the probability of failure on demand (POFOD) should be used. Finally, users or system operators may be mostly concerned that the system is available when a request for service is made. They will incur some loss if the system is unavailable. Availability (AVAIL) which takes into account repair or restart time, is then the most appropriate metric. There are three kinds of measurement, which can be made when assessing the reliability of a system:

1) The number of system failures given a number of systems inputs. This is used to measure the POFOD. 2) The time (or number of transaction) between system failures. This is used to measure ROCOF and MTTF. 3) The elapsed repair or restart time when a system failure occurs. Given that the system must be continuously available; this is used to measure AVAIL. Time is a factor in all of this reliability metrics. It is essential that the appropriate time units should be chosen if measurements are to be meaningful. Time units, which may be used, are calendar time, processor time or may be some discrete unit such as number of transactions.

B) Programming for Reliability There is a general requirement for more reliable systems in all application domains. Customers expect their software to operate without failures and to be available when it is required. Improved programming techniques, better programming languages and better quality management have led to very significant improvements in reliability for most software. However, for some systems, such as those, which control unattended machinery, these normal techniques may not be enough to achieve the level of reliability required. In these cases, special programming techniques may be necessary to achieve the required reliability. Some of these techniques are discussed in this chapter. Reliability in a software system can be achieved using three strategies: Fault avoidance: This is the most important strategy, which is applicable to all types of system. The design and implementation process should be organized with the objective of producing fault-free systems. Fault tolerance: This strategy assumes that residual faults remain in the system. Facilities are provided in the software to allow operation to continue when these faults cause system failures. Fault detection: Faults are detected before the software is put into operation. The software validation process uses static and dynamic methods to discover any faults, which remain in a system after implementation.

3. Suggest six reasons why software reliability is important. Using an example, explain the difficulties of describing what software reliability means. Ans: Reliability is the most important dynamic characteristic of almost all software systems. Unreliable software results in high costs for end-users. Developers of unreliable systems may acquire a bad reputation for quality and lose future business opportunities. The Reliability of a software system is a measure of how well users think it provides the services that they require. Reliability is usually defined as the probability of failure-free operation for a specified time in a specified environment for a specific purpose. Say it is claimed that software installed on an aircraft will be 99.99% reliable during an average flight of five hours. This means that a software failure of some kind will probably occur in one flight out of 10000. A formal definition of reliability may not equate to users experience of the software. The difficulty in relating such a figure to users experience arises because it does not take the nature of the failure into account. A user does not consider all services to be of equal importance. A system might be thought of as unreliable if it ever failed to provide some critical service. For example, say a system was used to control braking on an aircraft but failed to work under a single set of very rare conditions. If an aircraft crashed because of these failure conditions, pilots of similar aircraft would regard the software as unreliable. There is a general requirement for more reliable systems in all application domains. Customers expect their software to operate without failure to be available when it is required. Improved programming techniques, better programming languages and better quality management have led to very significant improvements in reliability for most software. However, for some systems, such as those which control unattended machinery, these normal techniques may not be enough to achieve the level of reliability required, In these cases special programming techniques may be necessary to achieve the required reliability. Software reliability is a function of the number of failures experienced by a particular user of that software. A software failure occurs when the software is executing. It is a situation in which the software does not deliver the service expected by the user. Software failures are not the same as software faults although these terms are often used interchangeably. Six reasons why software reliability is important:

1) Computers are now cheap and fast: There is little need to maximize equipment usage. Paradoxically, however, faster equipment leads to increasing expectations on the part of the user so efficiency considerations cannot be completely ignored. 2) Unreliable software is liable to be discarded by users: If a company attains a reputation for unreliability because of single unreliable product, it is likely to affect future sales of all of that companys products. 3) System failure costs may be enormous: For some applications, such a reactor control system or an aircraft navigation system, the cost of system failure is orders of magnitude greater than the cost of the control system. 4) Unreliable systems are difficult to improve: It is usually possible to tune an inefficient system because most execution time is spent in small program sections. An unreliable system is more difficult to improve as unreliability tends to be distributed throughout the system. 5) Inefficiency is predictable: Programs take a long time to execute and users can adjust their work to take this into account. Unreliability, by contrast, usually surprises the user. Software that is unreliable can have hidden errors which can violate system and user data without warning and whose consequences are not immediately obvious. For example, a fault in a CAD program used to design aircraft might not be discovered until several plane crashers occurs. 6) Unreliable systems may cause information loss: Information is very expensive to collect and maintains; it may sometimes be worth more than the computer system on which it is processed. A great deal of effort and money is spent duplicating valuable data to guard against data corruption caused by unreliable software.

Book ID: B0809 4. What are the essential skills and traits necessary for effective project managers in successfully handling projects? Ans: Project management can be defined as a set of principles, methods, tools, and techniques for planning, organizing, staffing, directing, and controlling project-related activities in order to achieve project objectives within time and under cost and performance constraints.

The effectiveness of the project manager is critical to project success. The qualities that a project manager must possess include an understanding of negotiation techniques, communication and analytical skills, and requisite project knowledge. Control variables that are decisive in predicting the effectiveness of a project manager include the managers competence as a communicator, skill as a negotiator, and leadership excellence, and whether he or she is a good team worker and has interdisciplinary skills. Project managers are responsible for directing project resources and developing plans, and must be able to ensure that a project will be completed in a given period of time. They play the essential role of coordinating between and interfacing with customers and management. Project managers must be able to: Optimize the likelihood of overall project success Apply the experiences and concepts learned from recent projects to new projects Manage the projects priorities Resolve conflicts Identify weaknesses in the development process and in the solution Identify process strengths upon completion of the project Expeditiously engage team members to become informed about and involved in the project Studies of project management in Mateyaschuk (1888), Sauer, Johnston, and Liu (1888), and Posner (1887) identify common skills and traits deemed essential for effective project managers, including: Leadership Strong planning and organizational skills Team-building ability Coping skills The ability to identify risks and create contingency plans The ability to produce reports that can be understood by business managers

 The ability to evaluate information from specialists Flexibility and willingness to try new approaches Feeny and Willcocks (1888) claim that the two main indicators of a project managers likely effectiveness are prior successful project experience and the managers credibility with stakeholders. The underlying rationale for this is that such conditions, taken together, help ensure that the project manager has the necessary skills to execute a project and see it through to completion and that the business stakeholders will continue to support the project; see also Mateyaschuk (1888) and Weston & Stedman (1888a,b). Research also suggests that the intangibility, complexity, and volatility of project requirements have a critical impact on the success of software project managers.

5. Which are the four phases of development according to Rational Unified Process? Ans: Rational Unified Process Model (RUP): The RUP constitutes a complete framework for software development. The elements of the RUP (not of the problem being modeled) are the workers who implement the development, each working on some cohesive set of development activities and responsible for creating specific development artifacts. A worker is like a role a member plays and the worker can play many roles (wear many hats) during the development. For example, a designer is a worker and the artifact that the designer creates may be a class definition. An artifact supplied to a customer as part of the product is a deliverable. The artifacts are maintained in the Rational Rose tools, not as separate paper documents. A workflow is defined as a meaningful sequence of activities that produce some valuable result (Krutchen 2003). The development process has nine core workflows: business modeling; requirements; analysis and design; implementation; test; deployment; configuration and change management; project management; and environment. Other RUP elements, such as tool mentors, simplify training in the use of the Rational Rose system. These core workflows are spread out over the four phases of development: The inception phase defines the vision of the actual user end-product and the scope of the project.

 The elaboration phase plans activities and specifies the architecture. The construction phase builds the product, modifying the vision and the plan as it proceeds. The transition phase transitions the product to the user (delivery, training, support, maintenance). In a typical two-year project, the inception and transition might take a total of five months, with a year required for the construction phase and the rest of the time for elaboration. It is important to remember that the development process is iterative, so the core workflows are repeatedly executed during each iterative visitation to a phase. Although particular workflows will predominate during a particular type of phase (such as the planning and requirements workflows during inception), they will also be executed during the other phases. For example, the implementation workflow will peak during construction, but it is also a workflow during elaboration and transition. The goals and activities for each phase will be examined in some detail. The purpose of the inception phase is achieving concurrence among all stakeholders on the objectives for the project. This includes the project boundary and its acceptance criteria. Especially important is identifying the essential use cases of the system, which are defined as the primary scenarios of behavior that will drive the systems functionality. Based on the usual spiral model expectation, the developers must also identify a candidate or potential architecture as well as demonstrate its feasibility on the most important use cases. Finally, cost estimation, planning, and risk estimation must be done. Artifacts produced during this phase include the vision statement for the product; the business case for development; a preliminary description of the basic use cases; business criteria for success such as revenues expected from the product; the plan; and an overall risk assessment with risks rated by likelihood and impact. A throw-away prototype may be developed for demonstration purposes but not for architectural purposes. The following elaboration phase ensures that the architecture, requirements, and plans are stable enough, and the risks are sufficiently mitigated, that [one] can reliably determine the costs and schedule for the project. The outcomes for this phase include an 80 percent complete use case model, nonfunctional performance requirements, and an executable architectural prototype. The components of the architecture must be understood in sufficient detail to allow a decision to make, buy, or reuse components, and to estimate the schedule and costs with a reasonable degree of confidence. Krutchen observes that a robust architecture and an understandable plan are highly correlated[so] one of the critical qualities of the architecture is its ease of construction. Prototyping entails integrating the selected architectural components and testing them against the primary use case scenarios.

The construction phase leads to a product that is ready to be deployed to the users. The transition phase deploys a usable subset of the system at an acceptable quality to the users, including beta testing of the product, possible parallel operation with a legacy system that is being replaced, and software staff and user training.

6. Describe the Capability Maturity Model with suitable real time examples. Ans: The Capability Maturity Model (CMM) is a service mark and a concept that was developed in the field of software development that provides a model for understanding the capability maturity of an organization's software development business processes. Because the CMM is about process maturity, it differs from more common maturity models that provide a structured collection of elements that describe certain aspects of maturity in an organization. The CMM is useful as a general theoretical model, to aid in the definition and understanding of an organization's process capability maturity. For software development, the CMM has been superseded by Capability Maturity Model Integration (CMMI). The Capability Maturity Model is an organizational model that describes 5 evolutionary stages (levels) in which an organization manages its processes. CMM describes 5 evolutionary stages in which an organization manages its processes. The thought behind the Capability Maturity Model, originally developed for software development, is that an organization should be able to absorb and carry its software applications. The model also provides specific steps and activities to get from one level to the next. The 5 stages of the Capability Maturity Model are: 1. Initial (processes are ad-hoc, chaotic, or actually few processes are defined) 2. Repeatable (basic processes are established and there is a level of discipline to stick to these processes) 3. Defined (all processes are defined, documented, standardized and integrated into each other) 4. Managed (processes are measured by collecting detailed data on the processes and their quality) 5. Optimizing (continuous process improvement is adopted and in place by quantitative feedback and from piloting new ideas and technologies) The Capability Maturity Model is useful not only for software development, but also for describing evolutionary levels of organizations in general and in order to describe the level of Value Based Management that an organization has realized or wants to aim for.

The higher the CMM maturity level is, the more disciplined, stable, and well-defined the development process is expected to be and the environment is assumed to make more use of automated tools and the experience gained from many past successes (Zhiying 2003). The staged character of the model lets organizations progress up the maturity ladder by setting process targets for the organization. Each advance reflects a further degree of stabilization of an organizations development process, with each level institutionalizing a different aspect of the process (Oshana & Linger 1999). Each CMM level has associated key process areas (KPA) that correspond to activities that must be formalized to attain that level. For example, the KPAs at level 2 include configuration management, quality assurance, project planning and tracking, and effective management of subcontracted software. The KPAs at level 3 include intergroup communication, training, process definition, product engineering, and integrated software management. Quantitative process management and development quality define the required KPAs at level 4. Level 5 institutionalizes process and technology change management and optimizes defect prevention. The CMM model is not without its critics. For example, Hamlet and Maybee (2001) object to its overemphasis on managerial supervision as opposed to technical focus. They observe that agreement on the relation between the goodness of a process and the goodness of the product is by no means universal. They present an interesting critique of CMM from the point of view of the so-called process versus product controversy. The issue is to what extent software engineers should focus their efforts on the design of the software product being developed as opposed to the characteristics of the software process used to develop that product. The usual engineering approach has been to focus on the product, using relatively straightforward processes, such as the standard practice embodied in the Waterfall Model, adapted to help organize the work on developing the product. A key point of dispute is that no one has really demonstrated whether a good process leads to a good product. Indeed, good products have been developed with little process used, and poor products have been developed under the guidance of a lot of purportedly good processes. Furthermore, adopting complex managerial processes to oversee development may distract from the underlying objective of developing a superior product. Hamlet and Maybee (2001) agree that, at the extremes of project size, there is no particular argument about the planning process to follow. They observe that for small-scale projects, the cost of a heavy process management structure far outweighs the benefits; however, for very large-scale projects that will develop multimillion-lines systems with long lifetimes, significant project management is clearly a necessity. However, in the midrange of projects with a few hundred thousand lines of code, the trade-offs between the managed model of development and the technical model in which the management hierarchy is kept to an absolute minimum

are less obvious; indeed, the technical model may possibly be the superior and more creative approach. Bamberger (1997), one of the authors of the Capability Maturity Model, addresses what she believes are some misconceptions about the model. For example, she observes that the motivation for the second level, in which the organization must have a repeatable software process, arises as a direct response to the historical experience of developers when their software development is out of control (Bamberger 1997). Often this is for reasons having to do with configuration management or mismanagement! Among the many symptoms of configuration mismanagement are: confusion over which version of a file is the current official one; inadvertent side effects when repairs by one developer obliterate the changes of another developer; inconsistencies among the efforts of different developers; etc.

February 2011 Master of Computer Application (MCA) Semester 3 MC0071 Software Engineering 4 Credits (Book ID: B0808 & B0809) Assignment Set 2 (60 Marks)

Message: This assignment I am giving you as a Sample. If you need all solved assignments then you can contact me on 09308351451 or ritesh.solution@gmail.com. All Solved assignments of all semesters of MCA (SMU only) are available.