MBA management

Software Engineering Process Patterns Framework, Assessment and Technology topics:

INTRODUCTION TO SOFTWARE ENGINEERING


In a fascinating book that provides an economist’s view of software and software engineering. Howard Baetjer, Jr. comments on the software process:

Because software, like all capital, embodies knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process. The process is a dialogue in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology]. It is an iterative process in which the evolving tool itself serves as the medium for communication, with each new round of the dialogue eliciting more useful knowledge from the people involved.

Indeed, building computer software is an iterative learning process, and the outcome, something that Baetjer would call “software capital”, is an embodiment of knowledge collected, distilled, and organized as the process is conducted.

But what exactly is a software process from a technical point of view? Within the context of this book, we define a software process as a framework for the tasks that are required to build high quality software .Is process synonymous with software engineering? The answer is yes and no. a software process defines the approach that is taken as software is engineered. But software engineering also encompasses technologies that populate the process---- technical methods and automated tools.

More important, software engineering is performed by creative, knowledgeable people who should adapt a mature software process that is appropriate for the products they build and the demands of their marketplace.

What is it? When you work to build a product or system, it‘s important to go through a series of predictable steps---- a road map that helps you create a timely, high–quality result. The road map that you follow is called a software process.

Who does it? Software engineers and their managers adapt the process to their needs and then follow it. In addition, the people who have requested the software have a role to play in the process of defining, building, and testing it.

Why is it important? Because it provides stability control, and organization to an activity that can, if left uncontrolled, become quite chaotic. However, a modern software engineering approach must be “agile”. It must demand only those activities, controls, and documentation that are appropriate for the project team and the product that is to be produced.

What are the steps? At a detailed level, the process that you adapt depends on the software that you’re building. One process might be appropriate for creating software for an aircraft avionics system, while an entirely different process would be indicated for the creation of a Web site.

What is the work product? From the point of view of a software engineer, the work products are the programs, documents, and data that are produced as a consequence of the activities and tasks defined by the process.

How do I ensure that I’ve done it right? There are a number of software process assessment mechanisms that enable organizations to determine the “maturity” of their software process. However, the quality, timeliness, and long-term viability of the product you build are the best indicators of the efficacy of the process of the process that you use.

A PROCESS FRAMEWORK


A process framework established the foundation for a complete software process by identifying a small number of frame work activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process.

The following generic process framework is applicable to the vast majority of software projects:

Communication. This frame work activity involves heavy communication and collaboration with the customer and encompasses requirements gathering and other related activities.

Planning. This activity establishes a plan for software engineering work that follows. It describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products that are to be produced, and a work schedule which is to be followed.

Modeling. The activity encompasses the creation of models that allow the developer and the customer to better understand software requirements and the design that will achieve those requirements.

Construction. This activity combines code generation and the testing that are required to uncover errors in the code.

Development. The software is delivered to the customer who evaluates the delivered products and provides feedback based on the evaluation.

These five generic framework activities can be used during the development of small programs, the creations of large web application, and for the engineering of large and complex computers- based systems. The details of the software process will be quite different in each case but the framework activities remain the same.

The framework described in the generic view of software engineering is complimented by a number of umbrella activities. Typical activities in this category include:

Software project tracking and control- allows the software team to access progress against the project plan and take necessary actions to maintain schedule.

Risk management- assesses risk that may affect the outcome of the projects or the quality of the product.

Software quality assurance- defines and conducts the activities required to ensure software quality.

Formal technical review- assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next actions or activity.

Measurement- defines and collects process, project, and product measures that assist the tam in delivering software that meets customer’s needs: can be used in conjunction with all other framework and umbrella activities.

Software configuration management- manages the effects of change throughout the software process.

Reusability management- defines criteria for work products reuse (including software components) and establishes mechanisms to achieve reusable components.

Umbrella activities are applied throughout the software process and are discussed in detail later in this book.

Madame Benoit: “I feel a recipe is only a theme which an intelligent cook can play each time with a variation.”

Process models that stress detailed definition, identification, and application of process activities and tasks, have been applied within the software engineering community for the past 30 years When these prescriptive process models are applied, the intent is to improve system quality, to make projects more manageable, to make delivery dates and costs more predictable, and to guide teams of software engineers as they perform the work required to build a system. Unfortunately, there have been times when these objectives were not achieved. If prescriptive models are applied dogmatically and without adaption, they can increase the level of bureaucracy associated with building computer- based systems and inadvertently create difficulty for developers and customers.

Process models that emphasize project agility and follow a set of principles that lead to a more informal (but, proponents argue, no less effective) approach to software process have been proposed in recent years. These are appropriate for many types of projects and are particularly useful when Web applications are engineered.

PROCESS PATTERNS


The software process can be defined as a collection of patterns that define a set of activities, actions, work tasks, work products and/or related behaviors required to develop computer software.

Patterns can be defined at any level of abstraction. In some cases, a pattern might be used to describe a complete process (e.g., prototyping). In other situations, patterns can be used to describe an important framework activity (e.g., planning) or a task within framework activity (e.g., project- estimating). Ambler has proposed the following template for describing a process pattern:

Pattern Name. The pattern is given a meaningful name that describes its functions within the software process (e.g., customer-communication).

Intent. The objective of the pattern is described briefly. For example, the intent of customer-communication is “to establish a collaborative relationship with the customer in an effort to define project scope, business requirements, and other projects constraints”.

Type. The pattern type is specified. Ambler suggests three types:

• Task pattern define a software engineering action or work task that is part of the process and relevant to successful software engineering practice (e.g., requirements gathering is a task pattern).

• Stage patterns represent a framework activity for the process. Since a framework activity encompasses multiple work tasks, a stage pattern incorporates multiple task patterns that are relevant to the stage. An example of a stage pattern might be communication. This pattern would incorporate the task pattern requirements gathering and others.

• Phase patterns define the sequence of framework activities is iterative in nature. An example of a phase pattern might be a spiral model or prototyping.

Initial context. The conditions under which the pattern applies are described. Prior to the initiation of the pattern, we ask (1) what organizational team created activities have already occurred (2) what is the entry state for the process? And (3) what software engineering information or project information already exists?

For example, the planning pattern (a stage pattern) requires that (1) customers and software engineers have established a collaborative communication: (2) successful completion of a number of task patterns (specified) for the customer-communication pattern has occurred: and (3) project scope, basic business requirements, and project constraints are known.

An Example Process Pattern:

The following abbreviated process pattern describes an approach that may be applicable when stakeholders have a general idea of what must be done, but are unsure of specific software requirements.

Pattern name. Prototyping.

Intent: The objective of the pattern is to build a model (a prototype) that can be assessed iteratively by stakeholders in an effort to identify or solidity software requirements.

Type: Phase pattern.

Initial context: The following conditions must be met prior to the initiation of this pattern:( 1) stakeholders have been identified; (2) a mode of communication between stakeholders and the software team has been established; (3) the overriding problem to be solved has been identified by stakeholders: (4) an initial understanding of project scope, basic business requirements, and project constraints has been developed.

Problem: Requirements are hazy or nonexistent, yet there is clear recognition that there is a problem, and the problem must be addressed with a software solution. Stakeholders are unsure of what they want; that is, they cannot describe software requirements in any detail.

Solutions: A description of the prototype that identifies basic requirements (e.g., modes of interaction, computational features, processing functions) is approved by stakeholders. Following this, (1) the prototype may evolve through a series of increments to become the production software or (2) the prototype may be discarded and the production software built using some other process pattern.

Related Patterns: The following patterns are related to this pattern: customer-communication; iterative design; iterative development, customer assessment; requirement extraction.

Known uses/examples: Prototyping is recommended when requirements are uncertain.

PROCESS ASSESSMENT


The process assessment is to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. A number of different approaches to software process assessment have been proposed over the past few decades:

1. Standard CMMI Assessment Method for Process Improvement (SCAMPI) provides a five—step process assessment model that incorporates initiating, diagnosing, establishing, acting, and learning. The SCAMPI methods use the SEI CMMI as the basis for assessment.

i. SPICE (ISO/IEC 15504) Standard defines a set of requirements for software process assessment. The intent of the standard is to assist organization in developing an objective evaluation of the efficacy of any defined software process.

ii. ISO9001: 2000 for Software is a generic standard that applies to any organization that wants to improve overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies.

The Capability Maturity Model Integration (CMMI)


The Software Engineering Institute (SEI) has developed a comprehensive process meta-model that is predicated on a set of system and software engineering capabilities that should be present as organizations reach different levels of process capability and maturity. To achieve these capabilities, the SEI contends that an organization should develop a process model that confirms to The Capability Maturity Model Integration (CMMI) guidelines.

The CMMI represents a process meta-model in two different ways: (1) as a Continuous model and (2) as a staged model. The continuous CMMI meta- model describes a process in two dimensions. Each process area (e.g., project planning or requirement) is formally assessed against specific goals and practices and is rated according to the following capability levels:

Level 0: Incomplete. The process area (e.g., requirements management) is either not performed or does not achieve all goals and objectives defined by the CMMI for level capability.

Level 1: Performed. All of the specific goals of the process area (as defined by the CMMI) have been satisfied. Work tasks required to produce defined work products are being conducted.

Level 2: Managed. All level I criteria have been satisfied. In addition, all work associated with the process area conforms to an organizationally defined policy; all people doing the work have access to adequate resources to get the job done; stakeholders are actively involved in the process area as required; all work tasks and work products are “monitored, controlled, and reviewed; and are evaluated for adherence to the process description”.

Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is “tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets.”

Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the process area is controlled and improved using measurement and quantitative assessment. “Quantitative objectives for quality and process performance are established and used as criteria in managing the process.”

Level 5: Optimized. All capability level 4 criteria have been achieved. In addition the process area is adapted and optimized using quantitative (statistical) means to meet changing customer needs and to continually improve the efficacy of the process area under consideration.”

Mark Paulk: “Much of the software crisis is self- inflicted, as when a C10 says, I’d rather it wrong than have it late. We can always fix it later.”

The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area to be effective. Specific practices refine a goal into a set of process- related activities.

For example, project planning is one of eight process areas defined by the CMMI for the “project management” category. The specific goal (SG) and the associated specific practices ( SP) defined for project planning are:

SG 1 Establish estimates

SP 1, 1-1 Estimate the scope of the project
SP 1, 2-1 Establish estimates of work product and task attributes
SP 1, 3-1 Define project life cycle
SP 1, 4-1 Determine estimates of effort and cost

SG 2 Develop a Project Plan

SP 2, 1-1 Establish the budget and schedule
SP 2, 2-1 Identify project risks
SP 2, 3-1 Plan for data management
SP 2, 4-1 Plan for project resources
SP 2, 5-1 Plan for needed knowledge and skills
SP 2, 6-1 Plan stakeholder involvement
SP 2, 7-1 Establish the project plan

SG 3 Obtain commitment to the plan

SP 3, 1-1 Review plans that affect the project
SP 3, 2-1 Reconcile work and resource levels
SP 3, 3-1 Obtain plan commitment

In addition to specific goals and practices, the CMMI also defines a set of five generic goals and related practices for each process area. Each of the five generic goals corresponds to one of the five capability level, the generic goal for that level and the generic practices that correspond to that goal must be achieved. To illustrate, the generic goals (SG) and practices (GP) for the project planning process area are:

GG 1 Achieve specific goals

GP 1.1 perform base practices

GG 2 Institutionalize a managed process

GP 2.1 Establish an organizational policy
GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign responsibility
GP 2.5 Train people
GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant stakeholders
GP 2.8 Monitor and control the process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management

GG 3 Institutionalize a defined process

GP 3.1 Establish a defined process
GP 3.2 Collect improvement information

GG 4 Institutionalize a quantitatively managed process

GP 4.1 Establish quantitative objectives for the process
GP 4.2 Stabilize sub-process performance

GP 5 institutionalize an optimizing process

GP 5.1 Ensure continuous process improvement
GP 5.2 Correct root causes of problems

The staged CMMI model defines the same process areas, goals, and practices as the continuous model. The primary difference is that the staged model defines five maturity levels, rather than five capability levels. To achieve a maturity level, the specific goals and practices associated with a set of process areas must be achieved. The relationship between maturity levels and process areas is shown.

The CMMI--- Should We or Shouldn’t We?


The CMMI is a process meta- mode. It defines (in over 700 pages) the process characteristics that should exist if an organization wants to establish a software process that is complete. The question that has been debated for well over a decade is: Is the CMMI an overkill? Like most things in life (and in software), the answer is not a simple yes or no.

The spirit of the CMMI should always be adopted. At the risk of oversimplification, it argues that software development must be taken seriously--- it must be planned thoroughly: it must be controlled uniformly: it must be tracked accurately: and it must be conducted professionally. It must focus on the needs of project stakeholders, the skills of the software engineers, and the quality of the end product. No one would argue with these ideas.

The detailed requirements of the CMMI should be seriously considered if an organization builds large complex systems that involve dozens or hundreds of people over many months or years. It may be that the CMMI is just in such situations, if the organizational culture is amenable to standard process models and management is committed to making it a success.

However, in other situations, the CMMI may simply be too much for an organization to successfully assimilate. Does this mean that the CMMI is bad or overly bureaucratic or old fashioned? No, it does not. It simply means that what is right for one company culture may not be right for another.

The CMMI is a significant achievement in software engineering. It provides a comprehensive discussion of the activities and actions that should be present when an organization builds computer software. Even if a software organization chooses not to adapt its details, every software team should embrace its sprit and gain insight from its discussion of software engineering process and practice.

PROCESS TECHNOLOGY


The generic process models discussed in the proceeding sections must be adapted for use by a software project team. To accomplish this, process technology tools have been developed to help software organizations analyze their current process, organize work tasks, control and monitor progress, and manage technical quality.

Process technology tools allow a software organization to build an automated model of the common process framework, task sets, and umbrella activities discussed earlier. The model, normally represented as a network, can then be analysed to determine typical work flow and examine alternative process structures that might lead to reduced development time or cost.

Once an acceptable process has been crated, other process technology tools can be used to allocate, monitor, and even control all software engineering tasks defined as part of the process model. Each member of a software team can use such tools to develop the checklist of work tasks to be performed, work products to be produced and a quality assurance activities to be conducted. The process technology tool can also coordinate the use of another computer-aided software engineering tools that are appropriate for a particular work task.

Process Modeling Tools:


Objective: If an organization work to improve a business (or software) process, it must first understand it. Process modeling tools (also called process technology or process management tools) are used to represent the key elements of a process so that it can be better understood. Such tools can also provide links to process descriptions that help those involved in the process to understand the actions and work tasks that are required to perform it. Process modeling tools provide links to other tools that provide support to defined process activities.

Mechanics: Tools in this category allow a team to define elements of a unique process model (actions, tasks, work products, QA points), provide detailed guidance on the content or description of each process element, and then manage the process as it is conducted. In some cases, the process technology tools incorporate standard project management tasks such as estimating, scheduling, tracking and control.

Representative Tools: Igrafx process Tools, distributed by Corel Corporation (www.igfx.com/product/process), is a set of tools that enable a tam to map, measure, and model the software process workflow definition and control.

Product and Process:

If the process is weak, the end product will undoubtedly suffer. But an obsessive over-reliance on process is also dangerous. In a brief essay, Margaret Davis comments on the duality of product and process:

About every ten Years, give or take five, the software community redefines “the problem” by shifting its focus from product issues. Thus, we have embraced structured programming languages (product) followed by structured analysis methods (process) followed by data encapsulation (product) Maturity Model (process) [followed by object- oriented methods, followed by agile software development].

While the natural tendency of a pendulum is to come to rest at a point midway between two extremes, the software community‘s focus constantly shifts because new force is applied when the last swing fails, These swings are harmful in and of themselves because they confuse the average software practitioner by radically changing what it means to perform the job, let alone perform it well. The swings also do not solve “the problem,” for they are doomed to fail as long as product and process are treated as forming a dichotomy instead of a duality.

There is precedence in this scientific community to advance notions of duality when contradictions in observations cannot be fully explained by one competing theory or another. The dual nature of light, which seems to be simultaneously particle and wave, has been accepted since the 1920s when Louie de Broglie proposed it. I believe that the observations we can make on the artifacts of software and its development demonstrate a fundamental duality between product and process. You can never derive or understand the full artifact, its context, use, meaning, and worth if you view it as only a process or only a product….

All of human activity may be a process, but each of us derives a self- worth from those activities that result in a representation or instance that can be used or appreciated either by more than one person, used over and over, or used in some other context not considered. That is, we derive feelings of satisfaction from reuse of our products by ourselves or others.

Thus, while the rapid assimilation of reuse goals into software development potentially increase the satisfaction software practitioners derive from their work, it also increases the urgency for acceptance of the duality of product and process. Thinking of a reusable artifact as only product or only process either obscures the context and ways to use it, or obscures software development activity. Taking one view over the other dramatically reduces the opportunities for ruse and, hence, loses the opportunity for increasing job satisfaction.

Benjamin Cardozo: “No doubt the ideal system, if it were attainable, would be a code at once so flexible and minute, as to supply in advance for every conceivable situation a just and fitting rule. But life is too complex to bring the attention of this idea within the compass of human power.”

People derive as much (or more) satisfaction from the creative process as thy do from the end-product. An artist enjoys the brush strokes as much as the finished book. A creative software professional should also derive as much satisfaction from the process as the end-product.

The work of software people will change in the years ahead. The duality of product and process is one important element in keeping creative people engaged as the transition from programming to software engineering is finalized.

Summary

• Software engineering is a discipline that integrates process, methods and tools for the development as computer software.

• The capability maturity model integration (CMMI) is a comprehensive process meta-model that describes the specific goals, problems and capabilities that should be present in a matured software process.

• The International organization for standardization (ISO) has developed thee ISO 9001: 2000 standards to define the requirements for a quality management system that will serve to produce higher quality products and thankfully improve customer satisfaction.

• The SEI’S CMMI describes the characteristic of a software process and criteria for a successful process in voluminous detail.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Review Questions
  • 1. What is software engineering? Describe the process framework and the various steps involved there under.
  • 2. Define the process pattern and explain the various objectives of process patterns.
  • 3. What is process assessment? Explain the various approaches to process assessment.
  • 4. What is CMMI? Explain the five step process assessment model under the CMMI assessment method and also the five generic goals thereof.
  • 5. What is process technology? Describe in detail the various concepts and practices under the process technology studies.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Related Topics
Software Engineering Process Patterns Framework, Assessment and Technology Keywords
  • Software Engineering Process Patterns Framework, Assessment and Technology Notes

  • Software Engineering Process Patterns Framework, Assessment and Technology Programs

  • Software Engineering Process Patterns Framework, Assessment and Technology Syllabus

  • Software Engineering Process Patterns Framework, Assessment and Technology Sample Questions

  • Software Engineering Process Patterns Framework, Assessment and Technology Subjects

  • EMBA Software Engineering Process Patterns Framework, Assessment and Technology Subjects

  • Software Engineering Process Patterns Framework, Assessment and Technology Study Material

  • BBA Software Engineering Process Patterns Framework, Assessment and Technology Study Material