HEMA.V Sikkim Manipal University DE Reg:No 511119346 Subject : MC0071-Software Engineering.

. Book ID: B0808 & B0809 Assignment 1 & 2

Book ID: B0808

1. What is the importance of Software Validation, in testing? Software Validation Also known as software quality control. Validation checks that the product design satisfies or fits the intended usage (high-level checking) i.e., you built the right product. This is done through dynamic testing and other forms of review. According to the Capability Maturity Model (CMMI-SW v1.1), Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]. Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610] In other words, validation ensures that the product actually meets the users needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that you built the right thing. Verification ensures that you built it right. Validation confirms that the product, as provided, will fulfill its intended use. From testing perspective: i. Fault wrong or missing function in the code. ii. Failure the manifestation of a fault during execution. iii. Malfunction according to its specification the system does not meet its specified functionality.Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar: iv. Validation is the process of determining the degree to which a model,simulation, or federation of models and simulations and their associated data are accurate representations of the real world from the perspective of the intended use(s). v. Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose. vi. Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developers conceptual description and specifications.

2. Explain the following concepts with respect to Software Reliability:

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 subsystems. 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. Software 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. Formal specifications and proof do not guarantee that the software will be reliable in practical use. The reasons for this are: (1) The specifications may not reflect the real requirements of system users many failures experienced by users were a consequence of specification errors and omissions, which could not be detected by formal system specification. It may even be the case that the opaqueness of formal notations makes it more difficult for users to establish whether or not a system meets their real requirements.

(2) The proof may contain errors Program proofs are large and complex so, like large and complex programs, they usually contain errors. (3) The Proof may assume a usage pattern, which is incorrect. If the system is not used as anticipated, the proof may be invalid.

Fig. 3.0: Shows cost Vs Reliability Because of additional design, implementation and validation overheads, increasing reliability can dramatically increase development costs. Figure 3.0 shown above is the relationship between costs and incremental improvements in reliability. If it is possible to measure if a system is 100% reliable as this would require an amount of time equal to the lifetime of the system. However, as reliability requirements increase, system costs usually rise exponentially. This is mostly due to the need of redundant hardware and a vast increase in testing costs to check that the required reliability has been achieved. As discussed some specifications, which call for, ultra-reliable systems are unrealistic. The number of tests required to validate these specifications cannot be carried out in a reasonable time. There is, of course, an efficiency penalty, which must be paid for increasing reliability. Reliable software must include extra, often redundant, code to perform the necessary checking for exceptional conditions. This reduces program execution speed and increases the amount of store required by the program. Reliability should always take precedence over efficiency for the following reasons: 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. The software process used to develop that product influences the reliability of the software product. A repeatable process, which is oriented towards defect avoidance, is likely to develop a reliable system. However, there is not a simple relationship between product and process reliability. Users often complain that systems are unreliable. This may be due to poor software engineering. However, a common cause of perceived unreliability is incomplete specifications. The system performs as specified but the specifications do not set out how the software should behave in exceptional situations. As professionals, software engineers must do their best to produce reliable systems, which take meaningful and useful actions in such situations.

Book ID: B0809 4. What are the essential skills and traits necessary for effective project managers in successfully handling projects?

A successful project manager knows how to bring together the definition and control elements and operate themefficiently. That means you will need to apply the leadership skills you already apply in running a department and practice the organizational abilities you need to constantly look to the future. In other words, if you are a qualifieddepartment manager, you already possess the skills and attributes for succeeding as a project manager. Thecriteria by which you will be selected will be similar. Chances are, the project you are assigned will have a directrelationship to the skills you need just to do your job. For example: Organizational and leadership experience:An executive seeking a qualified project manager usually seekssomeone who has already demonstrated the ability to organize work and to lead others. He or she assumes thatyou will succeed in a complicated long-term project primarily because you have already demonstrated therequired skills and experience. Contact with needed resources:For projects that involve a lot of coordination between departments, divisions,or subsidiaries, top management will look for a project manager who already communicates outside of a singledepartment. If you have the contacts required for a project, it will naturally be assumed that you are suited to run a project across departmental lines. Ability to coordinate a diverse resource pool:By itself, contact outside of your department may not beenough. You must also be able to work with a variety of people and departments, even when their backgroundsand disciplines are dissimilar. For example, as a capable project manager, you must be able to delegate andmonitor work not only in areas familiar to your own department but in areas that are alien to your background. Communication and procedural skills:An effective project manager will be able to convey and receiveinformation to and from a number of team members, even when particular points of view are different from hisown. For example, a strictly administrative manager should understand the priorities of a sales department, or acustomer service manager may need to understand what motivates a production crew. Ability to delegate and monitor work:Project managers need to delegate the work that will be performed byeach team member, and to monitor that work to stay on schedule

and within budget. A contractor who builds ahouse has to understand the processes involved for work done by each subcontractor, even if the work is highlyspecialized. The same is true for every project manager. It is not enough merely to assign someone else a task,complete with a schedule and a budget. Delegation and monitoring are effective only if you are also able to supervise and assess progress. Dependability:Your dependability can be tested only in one way: by being given responsibility and the chanceto come through. Once you gain the reputation as a manager who can and do respond as expected, you are readyto take on a project. These project management qualifications read like a list of evaluation points for everydepartment manager. If you think of the process of running your department as a project of its own, then youalready understand what it is like to organize a projectthe difference, of course, being that the project takes placein a finite time period, whereas your departmental tasks are ongoing. Thus, every successful manager should beready to tackle a project, provided it is related to his or her skills, resources, and experience 5. Which are the four phases of development according to Rational Unified Process? I.) Inception phase: During the inception phase, you establish the business case for the system and delimit the project scope. Toaccomplish this you must identify all external entities with which the system will interact(actors) anddefine the nature of this interaction at a high-level. This involves identifying all use cases anddescribing a few significant ones. The business case includes success criteria, risk assessment, and estimate of theresources needed, and a phase plan showing dates of major milestones. II.) Elaboration phase: The purpose of the elaboration phase is to analyze the problem domain, establish a soundarchitectural foundation,develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives,youmust have the mile wide and inch deep view of the system. Architectural decisions have to be made with anunderstanding of the whole system: its scope, major functionality and nonfunctional requirements such as performance requirements. III.) Construction phase: During the construction phase, all remaining components and application features aredeveloped and integrated into the product, and

all features are thoroughly tested. The construction phase is, in onesense, a manufacturing processwhere emphasis is placed on managing resources and controlling operations to optimize costs, schedules, andquality. In this sense, the management mindset undergoes a transition from the development of intellectual property during inception and elaboration to the development of deployable products during construction and transition.

IV)

Transition phase :

The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the user.issues would arise that require to develop new releases and correct defects. Finish the features that were postponed.

6. Explain Time is closely correlated with money and cost, tools, and the characteristics of development methodologies. What do you make out of this statement? The software engineering process depends on time as a critical asset as well as a constraint or restriction on the process. Time can be a hurdle for organizational goals, effective problem solving, and quality assurance. Managed effectively, time can support the competitive advantage of an organization, but time is also a limitation, restricting or stressing quality and imposing an obstacle to efficient problem solving. Time is the major concern of various stakeholders in the software engineering process, from users, customers, and business managers to software developers and project managers. Time is closely correlated with money and cost, tools, and the characteristics of development methodologies like Rapid Application Development that aim primarily at reducing time and accelerating the software engineering process. These methodologies exhibit characteristics such as reusability, which emphasizes avoiding reinventing the wheel, object-oriented analysis, design, and implementation. Examples include assembly from reusable components and component-based development; business objects; distributed objects; object-oriented software engineering and object-oriented business

process reengineering; utilizing unified modeling languages (UML); and commercial-offthe-shelf software. Other characteristics are automation (via CASE tools); prototyping; outsourcing; extreme programming; and parallel processing. A redefined software engineering process must integrate the critical activities; major interdisciplinary resources (people, money, data, tools, and methodologies); organizational goals; and time in an ongoing round-trip approach to business-driven problem solving. This redefinition must address limitations identified in the literature related to business metrics, the process environment and external drivers, and process continuation, as fundamentals of process definition. A conceptual framework should emphasize the following characteristics for interdisciplinary software engineering. It must address exploring resources, external drivers, and diversity in the process environment to optimize the development process. It must overcome knowledge barriers in order to establish interdisciplinary skills in software-driven problem-solving processes. It must recognize that organizational goals determine the desired business values, which in turn guide, test, and qualify the software engineering process. The process activities are interrelated and not strictly sequential. Irrelevant activities not related to or that do not add value to other activities should be excluded. The optimized software engineering process must be iterative in nature with the degree of iteration ranging from internal feedback control to continual process improvement. The software engineering process is driven by time, which is a critical factor for goals; competition; stakeholder requirements; change; project management; money; evolution of tools; and problem-solving strategies and methodologies.

Assignment 2
Book ID: B0808 1. Explain the following with respect to Configuration Management: A) Change Management B) Version and Release Management

A) Change Management: The change management process should come into effects when the software or associateddocumentation is put under the control of the configuration management team. Changemanagement 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 andchange tracking. The pseudo-code, shown in table below defines a process, which may be usedto manage software system changes:The first stage in the change management process is to complete a change request form (CRF).This is a formal document where the requester sets out the change required to the system. Aswell as recording the change required, the CRF records the recommendations regarding thechange, the estimated

costs of the change and the dates when the change was requested,approved, implemented and validated. It may also include a section where the maintenanceengineer outlines how the change is to be implemented.The information provided in the change request form is recorded in the CM database.Once a change request form has been submitted, it is analyzed to check that the change is valid.Some change requests may be due to user misunderstandings rather than system faults; othersmay refer to already known faults. If the analysis process discovers that a change request isinvalid duplicated or has already been considered the change should be rejected. The reason for the rejection should be returned to the person who submitted the change request. For valid changes, the next stage of the process is change assessment and costing. The impactof the change on the rest of the system must be checked. A technical analysis must be made of how to implement the change. The cost of making the change and possibly changing other system components to accommodate the change is then estimated. This should be recorded onthe change request form. This assessment process may use the configuration database wherecomponent interrelation is recorded. The impact of the change on other components may then be assessed.Unless the change involves simple correction of minor errors on screen displays or indocuments, it should then be submitted to a change control board (CCB) who decide whether or not the change should be accepted. The change control board considers the impact of thechange from a strategic and organizational rather than a technical point of view. It decides if thechange is economically justified and if there are good organizational reasons to accept thechange.The term change control board sounds very formal. It implies a rather grand group whichmakes change decisions. Formally structured change control boards which include senior clientand contractor staff are a requirement of military projects. For small or medium-sized projects,however, the change control board may simply consist of a project manager plus one or twoengineers who are not directly involved in the software development. In some cases, there mayonly be a single change reviewer who gives advice on whether or not changes are justifiable.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 softwaremust be revalidated to check that these changes have been correctly implemented. The CMteam, rather than the system developers, is responsible for building a new version or release of the software.Change requests are themselves configuration items. They should be registered in theconfiguration database. It should be possible to use this database to discover the status of change requests and the change requests, which are associated with specific softwarecomponents.As software components are changed, a record of

the changes made to each component should be maintained. This is sometimes called the derivation history of a component. One way tomaintain such a record is in a standardized comment prologue kept at the beginning of thecomponent. This should reference the change request associated with the software change.The change management process is very procedural. Each person involved in the process isresponsible for some activity. They complete this activity then pass on the forms and associated configuration items to someone else. The procedural nature of this process means that a change process model can be designed and integrated with a version management system. This modelmay then be interpreted so that the right documents are passed to the right people at the righttime. B) Version and Release Management: Version and release management are the processes of identifying and keeping track of differentversions and releases of a system. Version managers must devise procedures to ensure thatdifferent versions of a system may be retrieved when required and are not accidentallychanged. They may also work with customer liaison staff to plan when new releases of asystem should be distributed.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. Some versions may be functionally equivalent but designed for differenthardware or software configurations. If there are only small differences between versions, oneof these is sometimes called a variant of the other.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. Normally,there are more versions of a system than releases. Some versions may never be released tocustomers.For example, versions may be created within an organization for internal development or for testing.A release is not just an executable program or set of programs. It usually includes: (1)Configuration files defining how the release should be configured for particular installations. (2) Data files which are needed for successful system operation. (3) An installation program which is used to help install the system on target hardware. (4) Electronic and paper documentation describing the system.All this information must be made available on some medium, which can be read by customersfor that software. For large systems, this may be magnetic tape. For smaller systems, floppy disks may be used. Increasingly, however, releases are distributed on CD-ROM disks becauseof their large storage capacity.When a system release is produced, it is important to record the versions of the

operatingsystem, libraries, compilers and other tools used to build the software. If it has to be rebuilt atsome later date, it may be necessary to reproduce the exact platform configuration. In somecases, copies of the platform software and tools may also be placed under version management.Some automated tool almost always supports version management. This tool is responsible for managing the storage of each system version. 2. Discuss the Control models in details. Control models: The models for structuring a system are concerned with how a system is decomposed into sub-systems. To work as a system, sub-systems must be controlled so that their services aredelivered to the right place at the right time. Structural models do not (and should not) includecontrol information. Rather, the architect should organize the sub-systems according to somecontrol model, which supplements the structure model is used. Control models at thearchitectural level are concerned with the control flow between sub-systems.Two general approaches to control can be identified: (1)Centralized control: One sub-system has overall responsibility for control and starts andstops other sub-systems. It may also devolve control to another sub-system but will expect tohave this control responsibility returned to it. (2)Event-based control: Rather than control information being embedded in a sub-system,each sub-system can respond to externally generated events. These events might come fromother sub-systems or from the environment of the system.Control models supplement structural models. All the above structural models may beimplemented using either centralized or event-based control. Centralized control In a centralized control model, one sub-system is designated as the system controller and hasresponsibility for managing the execution of other sub-systems. Event-driven systems In centralized control models, control decisions are usually determined by the values of somesystem state variables. By contrast, event-driven control models are driven by externallygenerated events.The distinction between an event and a simple input is that the timing of

the event is outside thecontrol of the process which handless that event.A sub-system may need to access state information to handle these events but this stateinformation does not usually determine the flow of control.There are two event-driven control models: (1)Broadcast models: In these models, an event is, in principle, broadcast to all subsystems.Any sub-system, which is designed to handle that event, responds to it. (2)Interrupt-driven models: These are exclusively used in real-time systems where an interrupt handler detects external interrupts. They are then passed to some other component for processing.Broadcast models are effective in integrating sub-systems distributed across differentcomputers on a network. Interrupt-driven models are used in real-time systems with stringenttiming requirements.The advantage of this approach to control is that it allows very fast responses to events to beimplemented. Its disadvantages are that it is complex to program and difficult to validate. 3. Using examples describe how data flow diagram may be used to document a systemdesign. What are the advantages of using this type of design model? Data-flow models: Data-flow model is a way of showing how data is processed by a system. At the analysis level,they should be used to model the way in which data is processed in the existing system. The notations used in these models represents functional processing, data stores and datamovements between functions.Data-flow models are used to show how data flows through a sequence of processing steps. Thedata is transformed at each step before moving on to the next stage. These processing steps or transformations are program functions when dataflow diagrams are used to document asoftware design. Figure shows the steps involved in processing an order for goods (such ascomputer equipment) in an organization.

Data flow diagrams of Order processing The model shows how the order for the goods moves from process to process. It also shows thedata stores that are involved in this process.There are various notations used for data-flow diagrams. In figure rounded rectangles represent processing steps, arrow annotated with the data name represent flows and rectangles representdata stores (data sources). Data-flow diagrams have the advantage that, unlike some other modelling notations, they are simple and intuitive. These diagrams are not a good way todescribe sub-system with complex interfaces. The advantages of this architecture are: (1) It supports the reuse of transformations. (2) It is intuitive in that many people think of their work in terms of input and output processing. (3) Evolving system by adding new transformations is usually straightforward. (4) It is simple to implement either as a concurrent or a sequential system. Book ID: B0809

4. Describe the Classic Invalid assumptions with respect to Assessment of Process Life Cycle Models. Classic Invalid Assumptions:Four unspoken assumptions that have played an important role in the history of software development areconsidered next. First Assumption: Internal or External Drivers: The first unspoken assumption is that software problems are primarily driven by internal software factors. Granted this supposition, the focus of problem solving willnecessarily be narrowed to the software context, thereby reducing the role of people, money, knowledge, etc. interms of their potential to influence the solution of problems. Excluding the people factor reduces the impact of disciplines such as management (people as managers); marketing (people as customers); and psychology (peopleas perceivers). Excluding the money factor reduces the impact of disciplines such as economics (software in termsof business value cost and benefit); financial management (software in terms of risk and return); and portfoliomanagement (software in terms of options and alternatives). Excluding the knowledge factor reduces the impactof engineering; social studies; politics; language arts; communication sciences; mathematics; statistics; andapplication area knowledge (accounting, manufacturing, World Wide Web, government, etc).It has even been argued that the entire discipline of software engineering emerged as a reaction against thisassumption and represented an attempt to view software development from a broader perspective. Examples rangefrom the emergence of requirements engineering to the spiral model to humancomputer interaction (HCI). Nonetheless, these developments still viewed non-softwarefocused factors such as ancillary or external driversand failed to place software development in a comprehensive, interdisciplinary context. Because softwaredevelopment problems are highly interdisciplinary in nature, they can only be understood using interdisciplinaryanalysis and capabilities. In fact, no purely technical software problems or products exist because every software product is a result of multiple factors related to people, money, knowledge, etc., rather than only to technology. Second Assumption: Software or Business Processes: A second significant unspoken assumption has been thatthe software development process is independent of the business processes in organizations. This assumptionimplied that it was possible to develop a successful software product independently of the business

environmentor the business goals of a firm. This led most organizations and business firms to separate software developmentwork, people, architecture, and planning from business processes. This separation not only isolated the software related activities, but also led to different goals, backgrounds, configurations, etc. for software as opposed to business processes. As a consequence, software processes tended to be driven by their internal purposes, whichwere limited to product functionality and not to product effectiveness.This narrow approach had various negative side effects on software development. For example, the software process was allowed to be virtually business free. Once the product was finalized, it was tested and validated onlyfor functionality, as opposed to being verified for conformity to stakeholder goals. As a result, even if the productdid not effectively solve the underlying business problems or create a quantifiable business value for theorganization, it could still pass its test. Because software development was not synchronized with the business process, software problems could be solved without actually solving business problems. Third Assumption: Processes or Projects: A third unspoken assumption was that the software project wasseparate from the software process. Thus, a software process was understood as reflecting an area of computer science concern, but a software project was understood as a business school interest. If one were a computer science specialist, one would view a quality software product as the outcome of a development process thatinvolved the use of good algorithms, data base deign, and code. If one were an MIS specialist, one would view asuccessful software system as the result of effective software economics and software management. This dichotomy ignored the fact that the final product was identical regardless of who produced it or how it was produced. The assumption reinforced the unwise isolation of project management from the software development process, thus increasing the likelihood of product failure. In contrast to this assumption, interdisciplinary thinkingcombines the process with the project; computer science with the MIS approach; and software economics withsoftware design and implementation in a unified approach. Just as in the case of the earlier assumptions, thisassumption overlooks the role of business in the software development process. Fourth Assumption: Process Centered or Architecture Centered: There are currently two broad approaches insoftware engineering; one is process centered and the other is architecture centered. In process-

centered softwareengineering, the quality of the product is seen as emerging from the quality of the process. This approach reflectsthe concerns and interests of industrial engineering, management, and standardized or systematic qualityassurance approaches such as the Capability Maturity Model and ISO. The viewpoint is that obtaining quality in a product requires adopting and implementing a correct problem-solving approach. If a product contains an error,one should be able to attribute and trace it to an error that occurred somewhere during the application of the process by carefully examining each phase or step in the process.In contrast, in architecture-centered software engineering, the quality of the software product is viewed asdetermined by the characteristics of the software design. Studies have shown that 60 to 70 percent of the faultsdetected in software projects are specification or design faults. Because these faults constitute such a large percentage of all faults within the final product, it is critical to implement design-quality metrics. Implementingdesignquality assurance in software systems and adopting proper design metrics have become key to thedevelopment process because of their potential to provide timely feedback. This allows developers to reduce costsand development time by ensuring that the correct measurements are taken from the very beginning of the project before actual coding commences. Decisions about the architecture of the design have a major impact on the behavior of the resulting software particularly the extent of development required; reliability; reusability;understandability; modi-fiability; and maintainability of the final product, characteristics that play a key role inassessing overall design quality.However, an architecture-centered approach has several drawbacks. In the first place, one only arrives at thedesign phase after a systematic process. The act or product of design is not just a model or design architecture or pattern, but a solution to a problem that must be at least reasonably well defined. For example, establishing a functional design can be done by defining architectural structure charts, which in turn are based on previouslydetermined data flow diagrams, after which a transformational or transitional method can be used to convert thedata flow diagrams into structure charts. The data flow diagrams are outcomes of requirements analysis process based on a preliminary inspection of project feasibility. Similarly, designing object-oriented architectures in UMLrequires first building use-case scenarios and static object models prior to moving to the design phase.A further point is that the design phase is a process involving architectural, interface, component, data structure,and database design (logical and physical). The design phase cannot be validated or verified without correlating or matching its outputs to the inputs of the software development process. Without a process design, one could endup building a model, pattern, or architecture that was irrelevant or at least ambivalent because of the lack of metrics for evaluating

whether the design was adequate. In a comprehensive process model, such metrics areextracted from predesign and postdesign phases. Finally, a process is not merely a set of documents, but a problemsolving strategy encompassing every step needed to achieve a reliable software product that creates business value. A process has no value unless it designs quality solutions. 4. Describe the concept of Software technology as a limited business tool.

Software Technology as a Limited Business Tool:Software technology enables business to solve problems more efficiently than otherwise; however, as with anytool, 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 amore general problem-solving strategy. Software solutions should be seen as essential tools in problem solvingthat are to be combined with other interdisciplinary tools and capabilities. This kind of interoperation can beachieved by integrating such tools with the software development process. Additionally, the softwaredevelopment 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. 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 individualshave 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 inculture, values, attitudes, ethical standards, and religions Different goals, ambitions, and risk-management strategies Assorted levels of involvement and responsibilities in the business organizations processA 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 tochanges 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 differentorganizations and dispersed locations is an immense challenge. It entails building a customizable software systemand also necessitates a continuous development process to adapt to ongoing changes in the nature of theenvironment. 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 thesolution and, in some cases, they do not thoroughly investigate whether their final product reflects what usersasked 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 goalsappropriately and will fail its validation and verification criteria.In a utopian environment, end-users could become sufficiently knowledgeable in software developmentenvironments 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 sothe distance in functional intention between user languages and their translation into programming languages isoften considerable. This creates a barrier between software solutions reaching their intended market and users andcustomers 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, theusers 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 softwarearchitecture that can be coded in a programming language. Thus, the underlying objective in software engineeringis that the development solutions be truly reflective of user or customer needs. Decisions and Problems Complex and Ill Structured: The existence of a negative correlation between organizational complexity and the impact of technical change(Keen 1981) is disputed. More complex organizations have more ill-structured problems (Mitroff & Turoff 1963).Consequently, their technical requirements in terms of information systems become harder to address. On theother hand,

information technology may allow a complex organization to redesign its business processes so that it can manage complexity more effectively (Davenport & Stoddard 1994).On balance, a negative correlation is likely in complex organizations for many reasons. First, the complexity of anorganization increases the degree of ambiguity and equivocality in its operations (Daft & Lengel 1986). Many organizations will not invest resources sufficient to carry out an adequately representative analysis of a problem.Therefore, requirement specifications tend to become less accurate and concise. Implementing a system based ona poor systems analysis increases the likelihood of failure as well as the likelihood of a lack of compatibility withthe organizations diverse or competing needs. A demand for careful analysis and feasibility studies to allow athorough determination of requirements might bring another dimension of complexity to the original problem.Second, technology faces more people-based resistance in complex organizations (Markus 1983). This can occur because a newly introduced system has not been well engineered according to accurate requirements in the first place, as well as because of the combination of social, psychological, and political factors found in complexorganizations. One further factor complicating the effective delivery of computerized systems in large projects isthe time that it takes to get key people involved.Finally, there are obvious differences in the rate of growth for complex organizations and information technology.Although information technology advances rapidly, complex organizations are subject to greater inertia and thusmay change relatively slowly. Subsequently, incorporating or synthesizing technical change into an organization becomes a real challenge for individuals and departments and is affected by factors such as adaptability, training,the ability to upgrade, and maintainability. For such reasons, one expects a negative correlation betweenorganizational complexity and the impact of technical change in terms of applying software technology andachieving intended organizational outcomes. Business View Software Technology as a Black Box for Creating Economic Value: Although software systems play a significant role in business organizations in terms of business added value, thetraditional focus of many organizations has been on their role in cost reduction because software automation canreduce error, minimize effort, and increase productivity. Innovative applications can enable organizations toachieve more than traditional software goals, including the ability to compete more effectively, maximize profitability, and solve complex business problems.Business goals extend beyond direct financial

benefits to include operational metrics involving customer satisfaction, internal processes, and an organizations innovation and improvement activities. Indeed, suchoperational measures drive future financial performance (Van Der Zee & De Jong 1999). Efficiency, quality, andmarket share and penetration are other important goals and measures of business vitality (Singleton, McLean, &Altman 1988) that can be dramatically improved by software systems. Moreover, research has shown thatorganizational performance can be maximized by clearly recognizing the interdependence between social and technological subsystems (Ryan & Harrison 2000). Software systems with Web capabilities can enhance business added value even more effectively through their ability to reach customers, affiliate with partners, and enrichinformation (Evans & Wurster 1999).Although some small organizations use software systems only as one of many tools to achieve financial goals,many organizations have become partially or totally dependent on software systems. Comprehensive softwaresolutions are becoming the standard in many large organizations in which carefully thought out, unified softwarearchitectures are used to address business problems in levels of complexity that range from the operational toupper management and strategic levels.When an organization decides to assess whether it should develop a software system, a feasibility study is usuallycarried out to compare costs to benefits. Based on evaluating the appropriate organizational criteria and financialmetrics, managers can decide whether to move affirmatively towards selecting an information system from amongvarious alternative options. Organizations look at software as a tool that can make their businesses better, their customers happier, and their shareholders wealthier. Three criteria used in recent research on assessing businessvalue for IT-based systems are productivity, business profitability, and consumer surplus (Hitt & Brynjolfsson1996 and 1996).Requirements validation is also an important metric when building software systems; however, the traditionalforms of requirements focus on direct users needs and overlook business value in terms of comprehensive andquantifiable measurements. Although project management and fiscally driven factors are part of the softwareengineering process, they are often not integrated well into the process. Moreover, a gap remains between thediscipline of management information systems and the software development disciplines: MIS looks at solutionsfrom a managerial perspective, but technical concerns are more influential for software development. The directconnection between software development and business performance is inadequate and is not well quantified or recognized as a core of measures: general measures and emeasures. The arrows in Figure 6.1 are bidirectional because they reflect the mutual influences between the initial two variables of this framework. Business goalsshould be triggered to guide an optimal

software development process. Thus, this framework represents a view of the initial impact of business metrics on the development process. The effect of the development process on business performance is also a key concern. Although many problem-solving strategies are used in software process modeling, the overall software process can be viewed interms of certain basic elements or resources, such as activities, time, people, technology, and money. To reducecosts or increase benefits, one can think of combining activities; minimizing the cycle time; reducing the number of staff involved; maximizing profit; restructuring the composition of capital and finance; managing risk; or utilizing more technology. When the software process is reconsidered in these terms, business performance andmetrics become the decisive driving force for building software process models.Consequently, the software process has two related roles. The first role is internal: to assure software project payoff with better return on the information system investment, as discussed earlier. The second isexternal: the software process should make an actual difference in business performance. The first role has beenaddressed extensively in the software development and project management literature. However, few researchefforts have been dedicated to the study of the external impact of the software process on business performance.In fact, these roles should always be combined because external impacts cannot be studied without consideringinternal impacts. Figure 6.2 depicts this dual approach.This view represents the integration of the process and project themes and describes the evolution of software process models over the last several decades. Business value has always been embedded implicitly or explicitly in almost every progress in software process modeling. Minimization of time was behind the RapidApplication Development (RAD) and prototyping models. Risk control and reduction were major issues behindspiral models. The efficient use of human resources lies behind the dynamic models. The impact of user involvement in software process models reflects the importance of customer influence. Achieving competitiveadvantage in software systems is a key business value related to users and customers. However, little empirical examination of the affect of the different problem solving strategies adopted in software process models takes place.The interdependencies between the software process and business performance must be a key issue. The former is driven by the need for business value, and the latter in turn depends more than ever on software.This encompasses users, analysts, project managers,

software engineers, customers, programmers, andother stakeholders. Computer systems are human inventions and do not function or interact without human input.Some manifestations of this dependency are: Software applications are produced by people and are based on people needs. Software applications that do not create value will not survive in the marketplace. Computers cannot elastically adjust to real situations (they work with preexisting code and prescribed user inputs). Computers do not think; in terms of expertise, they reflect if then inputs or stored knowledge-based experiences. The main goal of software technology is to solve the problems of people.

This dependency on the human environment makes the automation that computers facilitate meaningless withouthuman involvement and underscores the limits of computer systems. It also highlights the central role that people play in making software technology an effective tool for producing desired outcomes. 5. Describe the round-trip problem solving approach.RoundTrip Problem-Solving Approach:The software engineering process represents a round-trip framework for problem solving in a business context inseveral senses. The software engineering process is a problem-solving process entailing that software engineering shouldincorporate 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 entailsestablishing 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 frequentlyrequires 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 toongoing changes in customer requirements and environmental pressures.