| Software Engineering: A Layered Technology | | | | · Software quality assurance |
| S.E is a layered technology. Any engineering approach | | | | · Formal technical reviews |
| must rest on an organization commitment to quality i.e. | | | | · Measurement |
| if the quality is good then we can build increasingly | | | | · Software configuration management |
| more matured project. | | | | · Reusability management |
| | | | | · Work product preparation and |
| Tools | | | | production |
| | | | | |
| Methods | | | | A Process Framework: |
| Process | | | | A common process |
| A | | | | framework is established by defining a small no of |
| quality focus | | | | activities that are applicable to all s/w projects |
| The foundation for software engineering is the | | | | regardless of their size or complexities. |
| process layer. Process defines a framework for a set | | | | A no of tasks sets each a |
| of key process areas (kpa’s) that must be | | | | collection of s/w engineering work tasks, project |
| established for effective delivery of s/w engineering | | | | milestones, work products; quality assurance points |
| technology. The kpa’s form the basis for | | | | enable the framework activities to be adapted to the |
| management control of software projects and | | | | characteristics of the s/w project and the |
| establish the context in which technical methods are | | | | requirements of the project |
| applied, data, reports etc are produced, quality is | | | | team. |
| ensured and change is properly managed. | | | | The Capability Maturity Model Integration (CMMI): |
| Software engineering methods provide the technical | | | | |
| how-to’s for building s/w i.e. they include | | | | Now-a-days there has been a significant emphasis on |
| requirements analysis, design, program construction, | | | | ‘process maturity’. The s/w engineering institute |
| testing and support | | | | (SEI) has developed a comprehensive model |
| Software engineering tools provide support for the | | | | predicated on asset of software engineering |
| process and the methods. When the tools are | | | | capabilities that should be present as organizations |
| integrated, so that info created by one tool can be | | | | reach different levels of process maturity. To |
| used by another, a system for the support for s/w | | | | determine an organization’s current state of |
| development called CASE is established. CASE | | | | process maturity the SEI uses an assessment that |
| combines s/w, h/w and s/w engineering database. | | | | results in a five point grading scheme i.e. by using |
| | | | | capability maturity model that defines key activities |
| A Generic view of software engineering: | | | | required at different levels of process maturity. |
| The work associated with s/w engineering can be | | | | There are six process maturity levels: |
| categorized into three generic phases regardless of | | | | · Level 0: Incomplete |
| application area, project size or complexity i.e. definition | | | | · Level 1: Initial, where few processes are |
| phase, development phase, and support phase. | | | | defined and success depends on individual effect. |
| · The definition phase focuses on what. | | | | · Level 2: Repeatable, basic project |
| That is during definition phase ,the software engineer | | | | management processes are established to track cost; |
| attempts to identify what info is to be processed, what | | | | schedule and functionality I.e. process discipline is |
| function and performance are desired, what interfaces | | | | repeated on projects with similar applications because |
| are to be established, what design constraints exists | | | | of their earlier successes. |
| and what validation criteria are required to define a | | | | · Level 3: Defined, the s/w process for |
| successful system. Thus the key requirements of | | | | both management and engineering activities are |
| system and the s/w are identified. | | | | documented, standardized and integrated into an |
| · The development phase focuses on | | | | organization wide s/w process |
| how. That is , during development a software engineer | | | | · Level 4: Managed, both the s/w |
| attempts to define how data are to be constructed, | | | | process and products are quantitatively understood |
| how function is to be implemented within a s/w | | | | and controlled using detailed measures. |
| architecture , how procedural details are to be | | | | · Level 5: Optimizing, continuous process |
| implemented, how interfaces are to be characterized, | | | | improvement is enabled by quantitative feedback from |
| how the design will be translated into programming | | | | the process and from testing innovative ideas and |
| language and how testing will be performed. The | | | | technologies. |
| results of this phase are s/w design, code generation | | | | The five levels defined by the SEI were derived |
| and s/w testing. | | | | as a consequence of evaluating responses to SEI |
| · The support phase focuses on change | | | | assessment questionnaire that is based on the CMM. |
| associated with error correction, adaptations required | | | | The results of questionnaire are distilled to a single |
| and changes due to enhancements brought about by | | | | numerical grade that provides an indication of an |
| changing customer requirements i.e. this phase | | | | organization’s process maturity. |
| reapplies the steps of definition and development | | | | The SEI has associated kpa’s with each of |
| phases. Four types of changes are encountered i.e. | | | | the maturity levels. Each kpa is described by identifying |
| correction, adaptation, enhancement and | | | | the following characteristics: |
| prevention.o Corrective maintenance | | | | · Goals: The overall objectives that the |
| changes the s/w to correct defects.o | | | | KPA must achieve. |
| Adaptive maintenance results on modification to the s | | | | · Commitments: requirements that must |
| w to accommodate changes to its external | | | | be met to achieve the goals. |
| environment (i.e.C.P.U, O.S etc).o As | | | | · Abilities: those things that must be in |
| software is used, the customer /user will recognize | | | | place to enable the organizations to meet the |
| additional functions that will provide benefit i.e. future | | | | commitments. |
| enhancements.o Preventive maintenance | | | | · Activities: the specific tasks required to |
| often called s/w engineering must be conducted to | | | | achieve the KPA function. |
| enable the s/w to serve the needs of its users I.e. it | | | | · Methods for monitoring implementation: |
| makes changes to computer programs so that they | | | | the manner in which the activities are monitored as |
| can be more easily corrects, adapted and enhanced. | | | | they are put into place. |
| | | | | · Methods for verifying implementation: |
| Generic process framework activities: | | | | the manner in which the proper practice for the KPA |
| Communication, planning, modeling, construction | | | | can be verified. |
| and deployment. | | | | |
| There are also a no of umbrella activities: | | | | Eighteen KPA’s have been defined across the |
| · Software project tracking and control | | | | maturity model and mapped into different levels of |
| · Risk management | | | | process maturity. |