Ads
  

Introduction to Software Engineering

Introduction to Software Engineering

Software engineering is not computer science nor is it merely rendering an idea into an abstract computer programming language. First coined in 1968, software development is the youngest recognized branch of engineering: "The phrase 'software engineering' was deliberately chosen for being provocative in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering." At the same conference, Fritz Bauer defined software engineering as: "the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines." Throughout this section there will be other definitions of software engineering for the practitioner software project manager to contemplate.

The Project Management Institute's Project Management Body of Knowledge (PMBOK) defines five project management process groups: initiating processes, planning processes, executing processes, controlling processes, and closing processes. This section introduces the software engineering executing processes of the software development project. The executing processes are where the estimated and scheduled resources are applied to carry out the project plan. Figure 1 shows the relative amount of effort expended in each process. Executing processes will take the largest amount of the project budget because of the level and amount of activity required to engineer quality software.

Project Management Processes

This section does not offer complete coverage of all areas of software engineering. Texts such as Roger Pressman's Software Engineering, A Practitioner's Approach, offer greater depth in the engineering areas. Software project managers must understand the processes for building high-quality software. This section exposes them to the existence of these concepts.

Where We Are in the Product Development Life Cycle

The planning and initiating phases have been completed, as well as the first pass at the software requirements specification. A project manager may have already had a prototype developed for proof-of-concept or feasibilities studies. This is the point at which all software engineering practices must be considered. From completion of all the requirements models to be included in the SRS through to the final delivery and installation, software engineering methods, techniques, and tools support the project executing processes. This period is shown in Figure 2.

Where the Executing Processes Occur in the Product Development Life Cycle

The IEEE Computer Society and ACM Software Engineering Coordinating Committee have joined together to produce the Software Engineering Body of Knowledge (SWEBOK). The support processes of the project life cycle are covered in the SWEBOK. This will be used to frame the life cycle in Figure 1 with the discipline of software engineering.

"Introduction to Software Engineering" Relation to the 34 Competencies

Software engineering relates most closely to several product management skills and to one project management skill. This is the point in the overall project management process where the project manager moves from planning and initiating the project to executing. The competencies that now apply fit most clearly with the active processes of developing software.

Product Development Techniques

1. Assessing processes

4. Evaluating alternative processes

8. Selecting methods and tools

9. Tailoring processes

Project Management Skills

17. Monitoring development

A project manager's ability to successfully guide the use of software engineering methods, techniques, and tools contributes greatly to the project reaching its development goals.

Learning Objectives for "Introduction to Software Engineering"

By the end of this section, the reader should be able to:

●  Discuss where software engineering occurs in the software development project life cycle;
●  Explain which of the 34 product, process, and people competencies support software engineering;
●  Describe how the Software Engineering Institute's capability maturity model employs software
    engineering in quality processes;
●  Define software engineering.

Software Engineering Defined in the SEI CMM

The CMM is a model of software process developed by a broad base of the software community. As a model it is, necessarily, a simplification of the actual engineering process. Being normative, the CMM identifies what should be expected of an organization at a given maturity level. Organizations that use it as a process measurement and improvement mechanism must apply a reasonable interpretation of the knowledge process areas in light of business objectives. With use as a process evaluation and measurement tool, the CMM becomes a road map to successful process improvement. Overall, the CMM is a grouping of sound engineering and management concepts based on proven principles of quality (e.g., TQM, Deming, Crosby). Software, embodied knowledge to be protected and valued, deserves such quality processes (Box 1).

The CMM is not prescriptive. It does not specify how an organization should achieve the process attributes. Neither is it a guarantee of instant success. Improvement takes time and sustained effort within the entire organization. It especially requires buy-in from executive management and a committed budget. The CMM is not a "one size fits all" methodology. The first step in its use is to customize the application of the maturity levels to a specific organization and project mix. SEI has developed other focused maturity models for organizational personal, software acquisition, systems engineering, integrated product development, and a personal software process.

Software Is Embodied Knowledge

One of the keys to using the CMM is to define what a mature process means. A mature software process has these attributes:

●  Defined - There is an established "way to do business."

●  Documented - It is written down so it can be known and used.

●  Trained - Training is based on the documentation.

●  Practiced - It is used, not "shelf-ware."

●  Supported - It is available, revised, and improved.

●  Controlled - Changes are approved by "stakeholders."

●  Verified - The process is executed correctly.

●  Validated - The intended process is executed.

●  Measured - Performance is measured as a basis for control and improvement of the process.

●  Able to be improved - It is flexible and able to be changed.

The benefits of a mature process become obvious with analysis. Schedules and budgets are based on historical performance and are realistic. Expected results for costs, schedule, and functionality are usually achieved. All participants understand the value of following a disciplined process consistently. Infrastructure exists to support the process (software engineering and its business aspects) and managers monitor the quality of software products and the process that produces them. The focus is on the process not the people.

Software product engineering is a key process area for Level 3, "Defined."

The purpose of Software Product Engineering is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.

Software Project Engineering involves performing the engineering tasks to build and maintain the software using the project's defined software process and appropriate methods and tools. The software engineering tasks include analyzing the system requirements allocated to software, developing the software requirements, developing the software architecture, designing the software, implementing the software in the code, integrating the software components, and testing the software to verify that it satisfies the specified requirements.

- Paulk, Weber, Curtis, and Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process

Goals

Goal 1. The software engineering tasks are defined, integrated, and consistently performed to produce the software.

Goal 2. Software work products are kept consistent with each other.   

Activities

Activity 1. Appropriate software engineering methods and tools are integrated into the project's defined software process.

Activity 2. The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the project's defined software process.

Activity 3. The software design is developed, maintained, documented, and verified according to the project's defined software process to accommodate the software requirements and to form the framework for coding.

Activity 4. The software code is developed, maintained, documented, and verified according to the project's defined software process to implement the software requirements and software design.

Activity 5. Software testing is performed according to the project's defined software process.

Activity 6. Integration testing of the software is planned and performed according to the project's defined software process.

Activity 7. System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its requirements.

Activity 8. The documentation that will be used to operate and maintain the software is developed and maintained according to the project's defined software process.

Activity 9. Data on defects identified in peer reviews and testing are collected and analyzed according to the project's defined software process.

Activity 10. Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures.

Software engineering is "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." Figure 3 is not a life cycle that can be followed and still engineer a project's software, but traditionally this is the model that has been followed. Developers take the incomplete requirements from a shortened requirements phase and write code until they have a program they think the user wants. It is normally a closed-loop system with the only feedback being self-referential within the developer group.

Do Not Use This Life Cycle


Tags

software process, software products, life cycle, software engineering, software development
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus