Design Heuristics for Effective Modularity from MI0024 MBA Assignment

“Summarize design heuristics for effective modularity.” The question of SMU MBA assignment for Software Engineering (MI0024) has to solve students. It is one more solved assignment for students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024. There are already some assignments of MBA MI0024 for students of SMU - Formal technical reviews, COCOMOL model and Linear Sequential Model.

Once the program structure has been developed, effective modularity can be achieved by applying the design concepts introduced earlier in this chapter. The program structure can be manipulated according to the following set of heuristics:

Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion. Once the program structure has been developed, modules may be exploded or imploded with an eye toward improving module independence. An exploded module becomes two or more modules in the final program structure. An imploded module is the result of combining the processing implied by two or more modules.

Attempt to minimize structures with high fan-out; strive for fan-in as depth increases. The structure shown inside the cloud does not make effective use of factoring. All modules are “packed” below a single control module. In general, a more reasonable distribution of control is shown in the upper structure.

Keep the scope of effective a module within the scope of control of that module.

The scope of effect of module is defined as all other modules that are affected by a decision made in module. The scope of control of module is all modules are subordinate and ultimately subordinate to module; if module makes a decision that affects module we have a violation of this heuristic, because module lies outside the scope of control module.

Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass information simply and should be consistent unrelated data passed via an argument list or other technique is an indication of low cohesion.

Define modules whose function is predictable, but avoid modules that are overly restrictive. A module is predictable when it can be treated as a black box; that is, the same external data will be produced regardless of internal processing details. Modules that have internal “memory” can be unpredictable unless care is taken in their use.

Strive for “controlled entry” modules by avoiding “pathological connections.” This design heuristic warns against content coupling. Software is easier to understand and therefore easier to maintain when module interfaces are constrained and controlled.

Formal Technical Reviews for MI0024 MBA Assignment of SMU

“Explain the formal technical reviews.” It is the question of SMU MBA assignment for Software Engineering (MI0024). It is for students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024. I have already written some assignments of MBA MI0024 for students of SMU - Earned value is a measure of progress, COCOMOL model and Linear Sequential Model.

A formal technical review is a software quality assurance activity performed by software engineers (and others). The objectives of the FTR are (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen.

(1) The review Meeting:

The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review. The FTR begins with an introduction of the agenda and a brief introduction by the producer.

(2) Review Reporting and Record Keeping:

The review summary report is a single page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties.

(3) Review Guidelines:

Guidelines for the conduct of format technical reviews must be established in advance, distributed to all reviewers, agreed upon, and then followed. A Review that is uncontrolled can often be worse that no review at all.

Explain Earned value is a Measure of Progress for Software Engineering Assignment of SMU MBA

“Earned value is a measure of progress. Explain this statement.” This is the question of this SMU MBA assignment for Software Engineering (MI0024). Students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024 can write the assignment. There are some other Software Engineering assignments also of SMU MBA - COCOMOL model, Linear Sequential Model and 4GL Technologies.

Earned value analysis provides the project manager with an indication of progress, but an assessment of the information provided is somewhat subjective. It is reasonable to ask whether there is a quantitative technique for assessing progress as the software team progresses through the work tasks allocated to the project schedule. In fact, a technique for performing quantitative analysis of progress does exist. It is called earned value analysis (EVA).

The earned value system provides a common value scale for every (software project) task, regardless of the type of work being performed. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total.

Stated even more simply, earned value is a measure of progress. It enables us to assess the “percent of completeness” of a project using quantitative analysis rather than rely on a gut feeling. In fact, Fleming and Koppleman argue that earned value analysis “provides accurate and reliable readings of performance from as early as 15% into the project”.

To determine the earned value, the following steps are performed:

1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. The work of each software engineering task is planned.

2. The BCWS values for all work tasks are summed to derive the budget at completion,

BAC. Hence, BAC=_(BCWSk) for all tasks k

3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.

COCOMOL Model of MI0024 Software Engineering for MBA Assignment

“Explain COCOMOL model.” You have to solve the question of SMU MBA MI0024 for Software Engineering. MBA students of Information System (IS) of Sikkim Manipal University MI0024 can write the assignment. I already have shared some other MI0024 MBA assignments also such as - Linear Sequential Model and 4GL Technologies.

In this classic book on “software engineering economics,” Barry Boehm [BOE81] introduced a hierarchy of software estimation models bearing the name COCOMO, for constructive cost model. The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. It has evolved into a more comprehensive estimation model, called COCOMO II [BOE96, BOE00]. Like its predecessor, COCOMO II is actually a hierarchy of estimation models that address that following areas:

Application composition model: Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount.

Early design stage model: Used once requirements have been stabilized and basic software architecture has been established.

Post-architecture-stage model: Used during the construction of the software.

The Software Project Plan is a relatively brief document that is addressed to a diverse audience. It must (1) communicate scope and resources to software management, technical staff, and the customer; (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software development for all people associated with the project; and (5) outline how quality will be ensured and change will be managed.

This is, the project team revisits the plan repeatedly – updating risks, estimates, schedules and related information – as the project proceeds and more is learned.

Similarly, the degree of detail contained within the schedule section may vary with the audience and formality of the plan. It is the important to note that the Software Project Plan is not a static document.

Linear Sequential Model in Software Engineering of MI0024 for SMU MBA Assignment

“Explain Linear Sequential Model.” It is the question of SMU MBA MI0024 for Software Engineering. Students of Information System (IS) of Sikkim Manipal University MBA MI0024 can write the assignment. There are some other MI0024 MBA assignments also such as - software process and different models and 4GL Technologies.

The linear sequential model suggests a systematic, sequential approach to software development. It begins at the system level and progress through analysis, design, coding, testing and support. Modeled after a conventional engineering cycle, the linear sequential model encompasses the following activities:

System/information engineering and modeling: Because software is always part of a larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interact with other elements such as hardware, people and databases.

Software requirements analysis: The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer (“analyst”) must understand the information domain for the software, as well as required function, behavior, performance and interface.

Design: Software design is actually a multistep process that focuses on four distinct attributes of a program: data structure, software architecture, interface representations and procedural detail. The design process translates requirements into a representation of the software that can be assessed for quality before coding begins.

Code generation: The design must be translated into a machine-readable form. The code generation step performs this task.

Testing: Once the code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested and on the functional externals, that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with the required results.

Support: Software will undoubtedly undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment or because the customer requires functional or performance enhancements.

The linear sequential model requires his and has difficult accommodating the natural uncertainty that exists at the beginning of many projects.

4GL Technologies for MBA Assignment of MI0024 Software Engineering

“What are 4GLs explain in brief.” The question has been taken from MI0024 SMU MBA of Software Engineering. It is the question of Information System (IS) for Sikkim Manipal University MBA MI0024. I have already shared software process and different models also for MI0024 assignment.

For small applications, it may be possible to move directly from the requirements gathering step to implementation using a nonprocedural fourth generation language (4GL), or a model composed of a network of graphical icons.

However, for larger efforts, it is necessary to develop a design strategy for the system, even if a 4GL is to be used. The use of 4GT without design (for large projects) will cause the same difficulties (poor quality, poor maintainability, poor customer acceptance) that have been encountered when developing software using conventional approaches.

Implementation using a 4GL enables the software developer to represent desired results in a manner that leads to automatic generation of code to create those results. Obviously, a data structure with relevant information must exist, and be readily accessible by the 4GL. To transform a 4GT implementation into a product, the developer must conduct through testing, develop meaningful documentation, and perform all other solution integration activities that are required in other software engineering paradigms. In addition, the 4GT developed software must be built in a manner that enables maintenance to be performed expeditiously.

Like all software engineering paradigms, the 4GT model has advantages and disadvantages. Proponents claim dramatic reduction in software development time and greatly improved productivity for people who build software. Opponents claim that current 4GT tools are not all that much easier to use than programming languages, that the resultant sources code produced by such tools is ‘inefficient,” and that the maintainability of large software systems developed using 4GT is open to question. 4GT begins with a requirements gathering step.

Software Process and Different Models Involved In This Process for MI0024 MBA Assignment

“Explain the software process and different models involved in this process.” This is MI0024 SMU MBA question assignment. The question has been taken from Software Engineering for Information System (IS) of SMU MBA MI0024. I have decided to write the assignment question after Branch and Bound Technique to solve an I.P.P. problem.

In the recent years, there has been a significant emphasis on “process maturity.” The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. To determine an organization’s current state of process maturity, the SEI uses an assessment that results in a five point grading scheme.

To solve actual problems is an industry setting, a software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods, and tools layers. All software development can be characterized as a problem solving loop in which four distinct stages are encountered: status quo, problem definition, technical development and solution integration.

This problem solving loop applies to software engineering work at many different levels of resolution. It can be used at the macro level when the entire application is considered, at a mid-level when program components are being engineered and even at the line of code level.

Software Process Models:

The Linear Sequential Model: Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggest a systematic, sequential approach to software development that begins at the system level and progress through analysis, design, coding, testing and support.

The Prototyping Model: Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements.

The Incremental Model: The incremental model combines elements of the linear sequential model with the iterative philosophy of prototyping.

The Spiral Model: The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.

The RAD Model: Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.

The intent of software engineering is to provide a framework for building software with higher quality. Software engineering is a discipline that integrates process, methods and tools for the development of computer software.