MAY 2011 Master of Computer Application (MCA) Semester 3 MC0071 Software Engineering 4 Credits

(Book ID: B0808 & B0809)

Assignment Set 1 (60 Marks)

Book ID: B0808 1. Choose a specific application and indicate a) the software application category into which it fits b) the data content associated with the application and c) the information determinacy of the application.. Ans. Lets take an example of web based application. (a) It fits into category Web Based Software. (b) Data content associated with this type of application is the input of form of meaning required to process the software application .Eg. the input data we provided on web pages accessed by browser handled by executable instructions. (c) Information determinacy of the application in this type of application become so massive as many users can access same application at a time as anyone can use this type of system with a modem. 2. Explain the following concepts with respect to Software Reliability: A) Software Reliability Metrics B) Programming for Reliability Ans. Software reliability is a function of the number of failures experienced by a particular user of that software.

(A) Software Reliability Metrics-The choice of software reliability metrics should be used
depends on the type of system to which it applies and the requirements of the application domain. so Metrics can be of following types as per system and requirement1.POFOD-Probability of failure on demand-This is a measure of likelihood that a system would fail when a service request is made .Eg. a POFOD of 0.001 means that 1 out of 1000 service request may result in failure.

2. ROCOF-Rate of failure occurrence-This is measure of the frequency of occurrence with which unexpected behavior is likely to occur.example-ROCOF 0f 2/100 means that 2 failures are likely to occur in each 100 operational units. sometimes called failure intensity. 3. MTTF-Mean time to failure-This is measure of time between observed system failure. 4. AVAIL-Availability-This is measure of how likely the system is to be available for use. Example - for 0.998 means that in every 1000 time units, the system is likely to be available for 998 of these.

(B) Programming for Reliability- Some special programming techniques are necessary to
achieve the required reliability. Programming types can be taken under below mentioned strategies1. Fault avoidance- The design and implementation system should be organized with the objectives of producing fault free systems . Structured Programming and error avoidance comes under this .Structured programming is term which is to mean programming without using go to statements, programming using only while loops and if statements as control constructs and designing using a top down approach.Structured programming means program can be read sequentially and are therefore easier to understand and inspect. Faults are less likely to be introduced into programs if the use of these constructs is minimized.These constructs include:Floating point numbers, pointer, dynamic memory allocation, parallelism, recursion, interrupts. 2. Fault Tolerance- A fault tolerant system can continue in operation after some system failures have occurred. There have been two comparable approaches to the provision of software fault tolerance .Both have been derived from the hardware model where a component is replicated. N version programming- Using a common specification, the software system is implemented in a number of different versions by different teams. 3. Fault detection: Faults are detected before the software is put into operation. The softwarevalidation 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. Below are the six reasons which explains why software reliability is important1. Computers are now cheap and fast 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 product. 3. System failure costs may be enormous: For some applications, such a reactor control 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-An unreliable system is more difficult to improve as unreliability tends to distributed throughout the system. 5. Inefficiency is predictable- Software that is unreliable can have hidden errors which can violate system and user data without warning and whose consequences are not immedialtely obvious. 6. Unreliable system may cause information loss It is difficult to explain what software reliability is as a common cause of perceived unreliability is incomplete specifications. So the system is performing which is specified but the specifications do not set out how the software behave in exceptional situations.

Book ID: B0809 4. What are the essential skills and traits necessary for effective project managers in successfully handling projects? Ans. Essential skills and traits necessary for effective project managers in successfully handling projects are1. Leadership 2. Strong planning and organizational skills 3. Team building ability 4. Coping Skills 5. The ability to indentify risks and create contingency plans 6. The ability to produce reports that can be understood by business managers 7. The ability to evaluate information from specialists

8. Flexibility and willingness to try new approaches

5. Which are the four phases of development according to Rational Unified Process? Ans. The four phases of development according to Rational Unified Process : 1. The inception phase defines the vision of the actual user end product and the scope of the project. 2. The elaboration phase plans activities and specifies the architecture. 3. The construction phase builds the product, modifying the vision and the plan as it proceeds. 4. The transition phase transitions the product to the user (delivery, training, support, maintenance) 6. Describe the Capability Maturity Model with suitable real time examples. Ans. The Capability maturity model is a multistage, process definition model intended to characterize and guide the engineering excellence or maturity of an organizations software development processes. The CMM guidelined for improving the software process contains an authoritative description.

Profile of Process Improvement Models

CMM identifies 5 levels of software development maturity in an organization. 1-At level 1, the organizations software development follows no formal development process. 2-The Process maturity is said to be at level 2 if software management controls have been introduced and some software process is followed. 3-An organization is said to be at level 3 if the development process is standard and consistent. 4-Organizations at level 4 are presumed to have put into place qualitative and quantitative measures of organizational process. 5-Oraganizations at maturity level 5 are assumed to have established mechanisms designed to ensure continuous process improvement and optimization.

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

Assignment Set 2 (60 Marks)

Book ID: B0808 1. Explain the following with respect to Configuration Management: A) Change Management B) Version and Release Management Ans. Change management- Change management process should come into effects when the software or associated documentation is put under the control of the configuration management team .Change management procedures should be designed to ensure that the costs and benefits of change are properly analyzed and that changes to a system are made in a controlled way, Change management processes involve technical change analysis , cost benefit analysis and change tracking. The first stage in the change management process is to complete a change request form.This is a formal document where the requester sets out the change required to the system.Once a change request form has been submitted , it is analyzed to check that the change is valid. For valid changes , the next stage of the process is change assessment and costing.The impact of the change on the rest of the system must be checked.Unless the changes involves simple correction of minor errors on screen displays or in documents , it should then be submitted to a change control board(CCB) who decides whether or not the change should be accepted.When a set of changes has been approved , the software is handed over to the development of maintenance team for implementation.once these have been completed , the revised software must be revalidated to check that these changes have been correctly implemented. Change requests are themselves configured items. They should be registered in the configuration database. As software component has been changed , a record of the changes made to each component should be maintained. This is sometimes called a deviation history of a component. Version and Release Management-Version and release management are the processes of identifying and keeping track of different versions and releases of a system. A system version is an instance of a system that differs , in some way from other instances. New versions of the system may have different functionality , performance or may repair system faults.

A System release is a version that is distributed to customers. Each System release should either include new functionality or should be intended for a different hardware platform. Release management New versions of a system may be created to fix reported faults or as part of the development process. In general creating a new system version involves creating new source code and building the system. Release management is complicated by the fact that customers may not actually want a new release of the system.They may consider that It is not worth the cost of changing to a new release. 2. What are the different stages of implementing a CMM?

Ans. The software process framework documented is intended to guide those wishing to assess an organization/projects consistency with the CMM. For each maturity level there are five checklist types: TypeSD Policy Standard Description Describes the policy contents and KPA goals recommended by the CMM. Describes the recommended content of select work products described in the CMM. Describes the process information content recommended by the CMM. The process checklists are further refined into checklists for:

Process

roles entry criteria inputs activities outputs exit criteria reviews and audits work products managed and controlled measurements documented procedures training

Procedure Level overview

tools Describes the recommended content of documented procedures described in the CMM. Provides an overview of an entire maturity level. The level overview checklists are further refined into checklists for:

KPA purposes (Key Process Areas)

KPA Goals policies standards process descriptions procedures training tools reviews and audits work products managed and controlled measurements

3. Using examples describe how data flow diagram may be used to document a system design. What are the advantages of using this type of design model? Ans. Data flow design: Data-flow design is concerned with designing a sequence of functional transformations that convert system inputs into the required. The design is represented as data-flow diagrams. These diagrams illustrate how data flows through a system and how the output is derived from the input through a sequence of functional transformations. Data-flow diagrams are a useful and intuitive way of describing a system. They are normally understandable without special training, especially if control information is excluded. They show end-to-end processing that is, the flow of processing from when data enters the system to where it leaves the system can be traced. Data-flow design is an integral part of a number of design methods and most CASE tools support data-flow diagram creation. Different methods may use different icons to represent data-flow diagram entities but their meanings are similar. The notation which use is based on the following symbols: Rounded rectangles represent functions, which transform inputs to outputs. The transformation name indicates its function. Rectangles represent data stores. Again, they should be given a descriptive name. Circles represent user interactions with the system which provide input or receive output. Arrows show the direction of data flow. Their name describes the data flowing along that path.

 The keywords and and or. These have their usual meanings as in Boolean expressions. They are used to link data flows when more than one data flow may be input or output from a transformation.

Book ID: B0809 4. Describe the Classic Invalid assumptions with respect to Assessment of Process Life Cycle Models. Ans. Four unspoken assumptions are as followsFirst assumption: Internal or External drivers-The first unspoken assumption is that software problems are primarily driven by internal software factors. Second assumption:Software or business processes-A second assumption has been that the software development process is independent of the business processes in organizations. Third assumption: Processes or Projects- A third assumption was that the software project was separate from the software process. Fourth Assumption: Process centered or architecture centered- there are currently two broad approaches in Software engineering; one is process centered and the other is architecture centered. 5. Describe the concept of Software technology as a limited business tool. Ans. Software Technology as a Limited Business Tool: Software technology enables business to solve problems more efficiently than otherwise; however, as with any tool, it has its limitations. Solving business problems involves many considerations that transcend hardware or software capabilities; thus, software solutions can only become effective when they are placed in the context of a more general problem-solving strategy. Software solutions should be seen as essential tools in problem solving that are to be combined with other interdisciplinary tools and capabilities. This kind of interoperation can be achieved by integrating such tools with the software development process. Additionally, the software development process can also be used as a part of a larger problem-solving process that analyzes business problems and designs and generates working solutions with maximum business value. Some examples of this are discussed in the following sections. 1. People have different needs that change over time Software technology is limited in its ability to recognize the application or cognitive stylistic differences of individuals or to adapt to the variety of individual needs and requirements. These differences among individuals have multiple causes and include:

 Use of different cognitive styles when approaching problem solving Variations in background, experience, levels and kinds of education, and, even more broadly, diversity in culture, values, attitudes, ethical standards, and religions Different goals, ambitions, and risk-management strategies Assorted levels of involvement and responsibilities in the business organizations process A software system is designed once to work with the entire business environment all the time. However, organizational needs are not stable and can change for many reasons even over short periods of time due to changes in personnel, task requirements, educational or training level, or experience. Designing a software system that can adjust, customize, or personalize to such a diversity of needs and variety of cognitive styles in different organizations and dispersed locations is an immense challenge. It entails building a customizable software system and also necessitates a continuous development process to adapt to ongoing changes in the nature of the environment. 2. Most Users Do not Understand Computer Languages A software solution can only be considered relevant and effective after one has understood the actual user problems. The people who write the source code for computer applications use technical languages to express the solution and, in some cases, they do not thoroughly investigate whether their final product reflects what users asked for. The final product is expected to convert or transform the users language and expectations in a way that realizes the systems requirements. Otherwise, the system will be a failure in terms of meeting its stated goals appropriately and will fail its validation and verification criteria. In a utopian environment, end-users could become sufficiently knowledgeable in software development environments and languages so that they could write their software to ensure systems were designed with their own real needs in mind. Of course, by the very nature of the division of expertise, this could rarely happen and so the distance in functional intention between user languages and their translation into programming languages is often considerable. This creates a barrier between software solutions reaching their intended market and users and customers finding reliable solutions. In many ways, the ideal scenario, in which one approached system design and development from a user point of view, was one of the driving rationales behind the original development of the software engineering discipline. Software engineering was intended as a problem-solving framework that could bridge the gap between user languages (requirements) and computer languages (the final product or source code). In software engineering, the users linguistic formulation of a problem is first understood and then specified naturally, grammatically, diagrammatically, mathematically, or even automatically; then, it is translated into a preliminary

software architecture that can be coded in a programming language. Thus, the underlying objective in software engineering is that the development solutions be truly reflective of user or customer needs. 6. Describe the round-trip problem solving approach. Ans. The software engineering process represents a round-trip framework for problem solving in a business context in several senses. The software engineering process is a problem-solving process entailing that software engineering should incorporate or utilize the problem-solving literature regardless of its interdisciplinary sources. The value of software engineering derives from its success in solving business and human problems. This entails establishing strong relationships between the software process and the business metrics used to evaluate business processes in general. The software engineering process is a round-trip approach. It has a bidirectional character, which frequently requires adopting forward and reverse engineering strategies to restructure and reengi-neer information systems. It uses feedback control loops to ensure that specifications are accurately maintained across multiple process phases; reflective quality assurance is a critical metric for the process in general. The nonterminating, continuing character of the software development process is necessary to respond to ongoing changes in customer requirements and environmental pressures.

MCA ASSIGNMENT-SEMESTER 3

NAME-MENKA JOSHI ROLL NOLC CODECOURSE-MCA DATE OF SUBMISSION-