Monthly Archives: November 2012

NATO 1968 – LANDMARK FOR SOFTWARE ENGINEERING

In early 1967, the NATO Science Committee, held discussion on “software engineering ” which comprised of scientists representing the various member nations in the field of computer science. Major motive for organizing the conference was to emphasize the increasing importance of software engineering.

This was the first time when the word “software engineering” came into existence. In the summit various issues related to software engineering were discussed like software engineering and society, design , production, service, software engineering as education, software pricing. Other agenda of scheduling meetings etc.were also discussed.

Nature of software engineering

Nash & Seling gave figures showing various activities in software development life cycle. They used the terms which being used in today’s life also. Seling gave most of the time to testing. Seling gave a figure which didn’t have feedback between the phase this was criticized by perlis so as to monitor the system & for future use. On this galler gave an example from his experience stated as “a request to allow user extensions of the PL/1 language. After a week of internal discussion at IBM it was decided that this could not be done because the language designers were not to tell the implementers how to implement the desired extensions.”

Seling gave External and internal design and their mutual feedback stated “External specifications at any level describe the software product in terms of the items controlled by and available to the user. The internal design describes the software product in terms of the program structures which realize the external specifications. It has to be understood that feedback between the design of the external and internal specifications is an essential part of a realistic and effective implementation process. Furthermore, this interaction must begin at the earliest stage of establishing the objectives, and continue until completion of the product.”

Image

Design

Firstly it was discussed that what could be the right way to approach for designing the software. Many suggestion were given by researchers in the field but the basic fundamental design concepts proposed dealt with concentration on the maintaining the software. That could be modularity, specification and generality.

While designing user requirement have to be also kept in mind. It is impossible to keep all user happy. Major problem is sometimes user himself doesn’t know what they need.

Production

Main problem is estimating the time required for completing the production. Some say we can estimate according to per instruction but there is no agreement on what the average cost will be for per instruction and also the ratio varies according to the phases of process in which you are in. If we talk practically no such data exists that can be used as an standard for the estimation. We have to rely on the experience of the worker and the judgment.

Service

Documentation from design and production aspect should be done. There can be two manuals: a general introduction to the solution of the problem by means of the package and a technical manual giving the exact available facilities and operation rules. These should be as attractive as possible.

Feedback to manufacturers from user is very important phase.

Other special topics were argued upon but couldn’t come to an solution to it. Every one had there own view in favor and against also

Issues were:

Should software be charged separately from hardware?

Software engineering as an different study in education?

Similarities between software engineering and computer science?

BY

PRACHEE KAMBOJ

Advertisements

CMMI-development. What is it all about?

Lillian Hellman said- “Things start out as hopes and end up as habits”. CMMI promises to show organizations the path of such a workspace conversion-where hopes become repeatable habits!

CMM- Capability Maturity Model was developed by Software Engineering Institute at  Carnegie Mellon University as commissioned by the US, Department of Defence. Later in 2010, CMM-Integrated was launched with separation of concerns such as Development, Services and Acquisition. The major changes were better description and marriage of cmmi with agile method(to end their made up cold war).

CMMI models are a set of practices which when followed thoroughly, can  improve  processes and their management.  CMMI makes life easy  by making the customer trust the organization  more, by helping to add value to the stocks and by giving a better recognition overall.

The CMMI document divides development into 22 core process areas such as Decision analysis and resolution, product integration etc.. Each area has components which are classified as required-MUST be visible in the organization, expected-important to achieve and  informative. Each process area is governed by a set of goals–  both SPECIFIC to the the  area and GENERIC. Achieving these goals is possible by following a detailed set of specific and generic practices given in the document. There are examples, subpractices and elaborations that give details about the implementation of practices. Click here to see the entire CMMIv1.3- development report. A generic goal is explained below as described in the document.

GG 3:Generic goal is “Institutionalise a Defined Process ”

Generic practices to be followed are

  1. Establish a Defined Process.
  2. Collect Improvement Information

 Subpractices are

  1. Store process and product measures in the organization’s measurement repository
  2. Submit documentation for inclusion in the organization’s process asset library
  3. Document lessons learned from the process for inclusion in the organization’s process asset library.
  4. Propose improvements to the organizational process assets

Examples of process related experiences for Product Integration area:

  • Records of the receipt of product components, exception reports, confirmation of configuration status, and results of readiness checking.
  • Percentage of total development effort spent in product integration (actual to date plus estimate to complete)
  • Defects found in the product and test environment during product integration
  • Problem reports resulting from product integration

CMMI can be applied for a team, workgroup etc. In a world of rating everything, from your personality to the pen that you use, why should software organizations be left behind. A provision for applying for appraisal and getting a rating according to the relevant maturity level is possible.

Level

Continuous Representation for process area. CAPABILITY Levels

Staged Representation for organisation. MATURITY Levels

Level 0 Incomplete– process partially performed              –
Level 1 Performed– needed work done to satisfy specific goals Initial- chaotic environment. Depends on heroics
Level 2 Managed- Planned and executed process as per policy Managed- planned execution
Level 3 Defined- standard practice according to tailored guidelines Defined-process standardization
Level 4            – Quantitatively Managed- quality management
Level 5            – Optimizing- innovation and deployment

Standard CMMI Appraisal Method for Process Improvement (SCAMPI)provides 3 classes of improvement to be applied at different levels. Class C is for few process areas and done within 3-5 days by Appraisal team member. Class B focuses on Deployment and a certified Lead appraiser is called in. Class A is stringent and is the basis for the final rating and focuses on institutionalisation and is done by a Lead Appraiser with a team. Example: Click here to see a sampling summary as published by SEI for Aricent.

The CMMI results published by SEI can be viewed by clicking here

Current research being carried out by SEI post CMMIv1.3 is

  • Tuning to process requirements in multi model environment
  • Studies of CMMI’s effect on Performance.
  • Mapping CMMI standards with IEEE,ISO etc to set a global standard.
  • tuning for improvement in small organization

A Spiral Model of Software Development and Enhancement

In software development process there was a need to maintain and follow a standard process to develop a software. people started to develop process model, winston W. Royce in the year 1970 came up with waterfall model.

The waterfall model served the purpose in the beginning but due to it’s linear design process failed to serve the purpose. In the year 1986 Barry Boehm came up with A Spiral Model of Software Development and Enhancement.

The spiral model is an iterative model for the software development process which added advantage through continuous refinement in software development phases like requirement phase, analysis phase, design phase and implementation.

Spiral model of software development establishes the transition criteria for progressing from one stage to the next with refinement on each iteration.

The radial dimension in Figure represents the cumulative cost incurred in accomplishing the steps to date; the angular dimension represents the progress made in completing each cycle of the spiral.

1

Each cycle of the spiral begins with the identification of  goal of portion of the product being elaborated,the alternative means of implementing this portion of the product and the constraints imposed on the application of the alternatives. Frequently this process with identify areas of uncertainly that are significant sources of project risk, once the risk is evaluated- the next step is determined by the relative remaining risks of the product development.

The risk-resolution activities done in the phase1 of spiral model includes surveys and analyses, including structured interviews of software developers and managers. plan in the next phase involves a partitioning into seperate activities to address managemnet improvements, facilities development and development of the  increments of a software development environment.

The key characteristic of a Spiral model is risk management at regular stages in the development cycle.

The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities:

  1. Formulate plans to: identify software targets, selected to implement the program, clarify the project development restrictions
  2. Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk
  3. Implementation of the project: the implementation of software development and verification

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows:

  1. The spiral model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developeras well as the willingness to spend more to fix the issues, which is the reason why this model is often used for large-scale internal software development.
  2. If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used.
  3. Software developers have to actively look for possible risks, and analyze it accurately for the spiral model to work.

The first stage is to formulate a plan to achieve the objectives with these constraints, and then strive to find and remove all potential risks through careful analysis and, if necessary, by constructing a prototype. If some risks can not be ruled out, the customer has to decide whether to terminate the project or to ignore the risks and continue anyway. Finally, the results are evaluated and the design of the next phase begins.

Spiral model has helped software engineers who can get there hands in and start working on project earlier. it is more able to cope with changes that software development entails. spiral model estimates to get more realistic as work progress. spiral model adds features in phases. product that is implemented using spiral model has increased it’s productivity to a larger extent.

By

kishore krishna

CMMI – DEV V 1.2

As some of the recently posted blogs have talked about CMMI, we will directly be going into the details of CMMI V1.2 for development.

CMMI-DEV basically is a collection of practices that, when implemented, improve product quality and also both project and organizational performance or we can say this model is a tool that helps organizations to improve their ability to develop and maintain quality products and services. CMMI-DEV organizes practices into 22 “process areas” with 13 practices, called “generic practices” .Based on the business needs and priorities, organizations select one or more process areas and sets of generic practices to implement.

A new version of CMMI is released every 3-5years. This process includes receiving requests for changes from users of previous version and these change requests are reviewed by a team of members from industry, government, and the SEI to determine the changes to make to the process areas, practices, and their descriptions.

The photo attached gives the overview of the process area of CMMI DEV and to which Maturity Level & category it belongs to in CMMI.

 Image

1. Requirements Management (REQM)

  • manage all requirements received or generated by the project, including both technical and nontechnical requirements.
  • also the requirements imposed by organization.

2. Project Planning (PP) : This area involves following activities

  • development of project plan.
  • interacting with the stakeholders.
  • maintain the plan developed.

3. Project Monitoring and Control (PMC) : In this process area we comprehend the project’s progress so that concerned corrective steps can be taken when the project’s performance deviates from the plan developed above.

4.Supplier Agreement Management (SAM) : This manage the acquisition of products and services from suppliers. A supplier agreement is established to manage the relationship between the organization and the supplier. A supplier agreement is any written agreement between the organization (representing the project) and the supplier. This agreement can be a contract, license, service level agreement, or memorandum of agreement.

5. Quantitative Project Management (QPM): This helps in achieving the project’s established quality and process performance objectives.

6. Integrated Project Management (IPM) : This basically establishes the project’s define process at project startup and manages the project using the project’s defined process. This also addresses the coordination of all activities associated with the project.

7. Risk Management (RSKM): As we all know, risk management is a continuous, that is an important part of project management. This involves the identification of potential risk before the occur, so that the predefined steps can be taken as and when needed throughout the life of project.

8. Measurement and Analysis (MA) : This involves-

  • specifying objectives of measurement and analysis.
  • specifying measures, analysis techniques, and mechanism for data collection, storage, reporting and feedback.
  • implementing the above specified techniques.

9. Process and Product Quality Assurance (PPQA): This involves-

  • evaluating the performed processed and work products against standards.
  • identifying and documenting the noncompliance issues.
  • giving feedback to project staff and managers.
  • ensuring that noncompliance issues are addressed.

10. Configuration Management (CM) : This serves the propose of establishing and maintaining the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

11. Decision Analysis and Resolution (DAR): The purpose of this process area is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. This involves establishing guidelines to determine which issues should be subject to a formal evaluation process and applying formal evaluation processes to these issues.

12. Causal Analysis and Resolution (CAR): The purpose of CAR is to identify causes of selected outcomes and take action to improve process performance, which in turns improves quality and productivity by preventing the introduction of defects or problems and by identifying and appropriately incorporating the causes of superior process performance.

13. Requirements Development (RD): The purpose of this process area is to establish requirements, which includes customer requirements, product requirements, and product component requirements.

14. Technical Solution (TS): This process area is applicable at any level of the product architecture. The purpose is to select, design, and implement solutions to requirements.

15. Product Integration (PI): This process area basically deals with the integration of components into more complex components or even complete product. Also it ensure that the product after integration behaves properly and then delivers the product.

16. Validation (VAL): As the term validation means finding or testing the truth of something in the same context this is used here. The purpose of validation is to check that the product fulfills its intended use when placed the environment where the product is to be used.

17.Verification (VER): This process area involves the verification of preparation and performance. The purpose is to ensure that selected work products meet their specified requirements.

18. Organizational Process Focus (OPF): This process area involves the through study and understanding of the organization’s processes and process assets so as to come out with the strengths and weakness to make the improvements.

19. Organizational Process Definition (OPD): This process area enable consistent process execution across the organization and provide a long-term benefits to the organization. The purpose is to is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

20.Organizational Training (OT): This deals with the training provided in the organization to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

21.Organizational Process Performance (OPP) : The purpose is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

22. Organizational Performance Management (OPM) : This involves the iteratively analyzing aggregated project data, identifying gaps in performance against the business objectives, and selecting and deploying improvements to close the gaps so that the organization meets its business objectives.

The following link gives the detailed description of the above mentioned process areas –http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI-DEV

EXTREME PROGRAMMING

Extreme programming is popular agile process. it is introduced in 6 march 1996.

EXTREME PROGRAMMING is efficient ,low risk,flexible,predictable,scientific and fun way to develop software. It is early,concrete and continuing feedback from short cycle.

It is an incremental planing approach.

It reliance on the automated written test by the programmer and customer to monitor the progress of development to allow system to evolve and locates the defects early .

EXTREME PROGRAMMING is a lightweight methodology for small to medium sized teams for developing software in rapidly changing environments.

EXTREME PROGRAMMING is successful because,it stress the customer satisfaction. extreme programming empowers the developers to confidently respond to the changing customer requirements.

Extreme programming emphasizes the team work.

Extreme programming customers , developers,managers are the equal partner in the collaborative team. it implements the simple ,effective environment which enables he team to become highly productive.

Extreme programming improves software project in five essential ways.

  1. Communication
  2. Simplicity
  3. Feedback
  4. Respect
  5. courage

Extreme programming constantly communicate with their customers and fellow programmers.

They keep their design simple and clean. they get feedbacks by testing their software testing on day one. They deliver the system to customers as early as possible and implements changes as suggested. every simple and small success deepens their respect for the unique contribution of each and every team member.

With this foundation extreme programming are able to courageously respond to changing requirements and technology.

The flow chart shows how the extreme programming rules work together. Customers enjoy being partners in the software process,developers actively contribute regardless of experience level,and managers concentrates on communications and relationships.

Unproductive activities have been trimmed to reduce costs and frustration of every one involved.

The flowchart is shown in below

WHY THE “EXTREME” IN THE NAME?

Extreme programming takes common principles and practices to extreme level.

  1. If code reviews are good ,we will review the code all the time (pair programming).
  2. If testing is good,everybody will test all the time (unit testing), even the customers (functional testing).
  3. If the design is good,we will make it part of everybody’s life (refactoring).
  4. If short relations are good, we will make the relations really (planning game).

Extreme programmers work together in pairs and as a group,with simple design and improving the design continually to keep it always just right for the current needs.

EXTREME PROGRAMMING team use a simple form of planning and tracking to decide what should be done in next and to predict when project will be done.

The extreme programming team keeps the system integrate and running all the time. the programmers write all the production code in pairs.

The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed.

The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.

XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project — which is quite straightforward — rather than on exact prediction of what will be needed and how long it will take — which is quite difficult. There are two key planning steps in XP, addressing these two questions:

Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the cost estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won’t know just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.

Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week “iterations”, delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.

Conclusion

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

NATO 1968 – LANDMARK FOR SOFTWARE ENGINEERING

In early 1967, the NATO Science Committee, held discussion on “software engineering ” which comprised of scientists representing the various member nations in the field of computer science. Major motive for organizing the conference was to emphasize the increasing importance of software engineering.

This was the first time when the word “software engineering” came into existence. In the summit various issues related to software engineering were discussed like software engineering and society, design , production, service, software engineering as education, software pricing. Other agenda of scheduling meetings etc.were also discussed.

Nature of software engineering

Nash & Seling gave figures showing various activities in software development life cycle. They used the terms which being used in today’s life also. Seling gave most of the time to testing. Seling gave a figure which didn’t have feedback between the phase this was criticized by perlis so as to monitor the system & for future use. On this galler gave an example from his experience stated as “a request to allow user extensions of the PL/1 language. After a week of internal discussion at IBM it was decided that this could not be done because the language designers were not to tell the implementers how to implement the desired extensions.”

Seling gave External and internal design and their mutual feedback stated “External specifications at any level describe the software product in terms of the items controlled by and available to the user. The internal design describes the software product in terms of the program structures which realize the external specifications. It has to be understood that feedback between the design of the external and internal specifications is an essential part of a realistic and effective implementation process. Furthermore, this interaction must begin at the earliest stage of establishing the objectives, and continue until completion of the product.”

Image

Design

Firstly it was discussed that what could be the right way to approach for designing the software. Many suggestion were given by researchers in the field but the basic fundamental design concepts proposed dealt with concentration on the maintaining the software. That could be modularity, specification and generality.

While designing user requirement have to be also kept in mind. It is impossible to keep all user happy. Major problem is sometimes user himself doesn’t know what they need.

Production

Main problem is estimating the time required for completing the production. Some say we can estimate according to per instruction but there is no agreement on what the average cost will be for per instruction and also the ratio varies according to the phases of process in which you are in. If we talk practically no such data exists that can be used as an standard for the estimation. We have to rely on the experience of the worker and the judgment.

Service

Documentation from design and production aspect should be done. There can be two manuals: a general introduction to the solution of the problem by means of the package and a technical manual giving the exact available facilities and operation rules. These should be as attractive as possible.

Feedback to manufacturers from user is very important phase.

Other special topics were argued upon but couldn’t come to an solution to it. Every one had there own view in favor and against also

Issues were:

Should software be charged separately from hardware?

Software engineering as an different study in education?

Similarities between software engineering and computer science? 

BY 

PRACHEE KAMBOJ

PEOPLE CAPABILITY MATURITY MODEL

                PEOPLE  CAPABILITY  MATURITY  MODEL

The People capability maturity(pcmm) model came into existence in the year 1995.

The main objective of this pcmm is to manage and develop the workforce of  organization. The workforce in the sense ,the level of knowledge and skills that are available for forming the organization.

Actually before this there was Capability Maturity Model(CMM) but it focused on the organization process.

Whereas this PCMM focus on the developing the organization workforce.

As CMM has five maturity levels, this PCMM also has five maturity levels.

So this each maturity level helps to improve the organizational workforce.

If the organization has more mature , then it has greater capability to develop,

Attract  and retain the talented  persons .

The five maturity levels are

1)Initial level

2)Managed level

3)Defined level

4)Predictable level

5)Optimizing level

INITIAL LEVEL:

it is the first maturity level, it is called  adhoc process. Here the organizational will perform things and tasks in random. So the organizational level will have some success and some failures.

MANAGED LEVEL:

It is the second maturity level. It mainly focuses on the managers to take

Responsibilities for managing and developing their people .

The workforce practices implemented in this level focus on activities at uinit level.

DEFINED LEVEL :

It is the third maturity level. Here it mainly focuses on developing its organization workforce. These workforce represent the critical pillars, in supporting the stratergic business plan.

PREDICTABLE LEVEL :

It is the fourth maturity level, the workforce compentices that were created at the defined level will be managed at this level.

OPTIMIZING LEVEL:

At optimizing level , the entire organizational is focused on the continual improvement of the workgroup and organizational capability.