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