|Product dimensions:||6.00(w) x 9.00(h) x 0.38(d)|
Software Engineering Notebook
By Bernard Carrier Gerry Tarum
AuthorHouseCopyright © 2010 Bernard Carrier and Gerry Tarum
All right reserved.
Since the days of Galileo, Newton and Einstein, our universe appears almost reachable. Beyond the awe in the knowledge displayed, our imagination goes wild " to go where no one has gone before".
Software, like the constellations, displays an awesome sense of unreachable limits and, like the stars, has far reaching influence on our daily lives. The ability to screen the North Star allowed our ancestors the potential to navigate to distant continents. The ability to discern patterns and to discern or infer new constellations, allowed the Incas and Egyptians to reach beyond the mathematical knowledge of those days.
This book is about imagination, creativity and discovery. You are not about to discover nebulas or wormholes in some time distorted spaces. However, your imagination and creativity will dictate how far you want to travel in the domain of Software Engineering (SE), through a path of your choosing (Figure 1).
Appendices A to J illustrate the concepts. Appendix I will test your knowledge using a Sudoku based approach. Four patterns, illustrated in Figure 2, form the basis of this book, exemplified in the appendices listed:
Plan the work pattern, detailed in Appendix A; Work the plan pattern, detailed in Appendix B; Plan the measure pattern, detailed in Appendix C; and Work the measure pattern, detailed in Appendix D.
The ability to discern persistent knowledge in software is coined "Cognitive Engineering". This book, like in a planetarium, allows you in the comfort of your chair to watch and listen to Jean Luc offering you a unique moment to master knowledge that will boost you at warp speed, using your imagination and abilities, into grasping more knowledge in Software Engineering.
When Captain Picard commanded "Engage", the goals of his mission (Figure 3), and the problems or questions to explore were set in his mind. He had full confidence in his crew to respond in an efficient and effective fashion, through experience in numerous missions. Problems and questions are set in your mind and you have full confidence in you and your associate ability to respond in an efficient and effective manner.
This represents the first step in Software Engineering. The Chess Game evaluator presented herein (Figure 4) illustrates such steps
Our Mission is to create Intelligent Agents, illustrated in Figure 6 and described below, to assist software engineers to apply organization specific cognitive functions to effectively meet the responsibilities of their role under various project assignments in order to reach maximum Return On Investment (ROI).
Like exploring the Milky Way, our first galaxy, this book explores the Chess Game. Chess, by itself, remains a fascinating and elusive game. Think of Gary Kasparov, a chess expert, challenged by the Big Blue from IBM. Kasparov did not fight against a Borg, but against a machine. Big Blue merely represented a wealth of knowledge gathered from numerous chess experts and Big Blue represented a challenge to Kasparov. This is what Software Engineering is all about "Challenge".
The multi-faceted approach (Figure 5) proposed herein will allow you to discover a wealth of information and experience. For the curious explorer, Appendix B will provide a detailed insight into the conceptual framework presented. Our Vision is to establish a Software Engineering Economics Model (SEEM) that will capture the modern principles of software engineering and incorporate key estimate factors required to achieve the economic results expected.
The Goals pursued are as follows:
First, it is easier for a software engineer to learn concepts when simultaneously presented with a basic principle and one or more specific examples of that principle. The examples provided allow the engineer with a structure to derive, test and adjust his understanding of basic principles. The engineer can also apply the basic principles. Second, a software engineer learns by doing "I hear, I forget; I see, I remember; I do I understand". But one must perform investigative work in order to start experimenting. The goal here is to provide a starting framework that facilitates the investigation and creates an experimental environment. Experiments provide the user with a framework to apply his knowledge under known applications and acquire new knowledge through experiment. Third, the environment must be rich enough to have interesting internal interaction among the parts by dealing with practical design issues and issues encountered in developing complex systems. The environment provides the user with the capabilities to explore hands-on system development and acquire new skills through experiment. Fourth, the knowledge and skills covered should range from basic to advance level using Bloom's Taxonomy. The goal is to provide an iterative and incremental knowledge-based system to assist users in various and complex project activities. The Cognitive Engineering System (CES) assists end-users in decision-making and problem solving by providing concepts, principles, methodologies, and technologies consistent with the issues at hand. The system allows end-users to assess productivity and efficiency of solutions and acquire the Cognitive Engineering (CE) skills required to conduct the Software Engineering activities.
The Problem Solving Approach applied is the tailoring of the Software Engineering Process Architecture (SEPA) to a specific project. The process requires looking at your project from a variety of views presented under Appendix B, namely:
Management view; Engineering view; Process view; Pragmatics view; and Verification & Validation view.
This Iterative and Incremental Process indicated above is captured using a Software Engineering Process (SEP) illustrated below (Figure 6).
In this book, the Cognitive Engineering System (sections 2.0 and 3.0) captures the project view while the Control System (section 6.0) captures the management views such as:
Project Management (PM) view (section 4.1); System Management (SM) view (section 4.2); Quality Management (QM) view (section 4.4); Verification & Validation (V&V) view (section 4.5); Risk Management (RM) view (section 4.6); Configuration Management (CM) view (section 4.7); Infrastructure Management (IM) view (section 4.8); and Process Improvement (PI) Management view (section 4.10).
The Process view is captured by the Software Engineering Exploration System Agent (SEES) (section 4.0) and the Pragmatics View is captured by the Integrated System Environment Agent (ISE) (section 5.0).
The Management views above are not product development phase dependent. Hence, the overall management activities are coined Integral Engineering. The engineering activities, on the other hand are phase dependent, hence coined Production Engineering.
The CES captures the Engineering view (section 7.0) using a Prototyping System Agent (PS) that captures the following views:
Software Engineering view (section 4.3); and Maintenance Management (MM) view (section 4.9).
The Verification & Validation view (section 8.0) is captured by the Performance Support System Agent (PSS). The Expert System Agent (ES), described in section 5.0 merely serves as a mechanism to query and search the standards, the procedures, the rules and guidelines that apply throughout the product development process. The Project Repository Broker Agent (PRB) merely represents a repository for these rules and accesses both locally and remotely. An expert in a domain of study could update these rules interactively. The Cultural Values supported are based on modern principles of Software Engineering and allow the organization to implement best practices to support a project.
2.1 Team building
In ancient times, discoverers relied on very crude maps to navigate the continents. Sea captains could read stars, create maps and set new courses with as much mastery as their ability to control the wind through their sails. In addition, through experience, a Captain such as Captain Cook memorized sea currents and seasonal wind movements to effectively and efficiently reach foreign destinations. More importantly, his ability to motivate and train his crew allowed him to navigate through tricky and dangerous shores with relative ease. But disaster can happen, attested by Captain Cook's fate. The idea is to learn a way of thinking, the System's Way of Thinking (Figure 7), to avoid production disasters.
2.2 Leadership applied
The main goal of the process is to allow the reader to experience the life of a Project Manager, through his journey in developing a Chess Game Evaluator for a tournament chess team (Figure 8).
Scenarios with various levels of complexity allow you to experience small to medium size projects with confidence and anticipation. You will experience the Tools & Techniques that will allow for a successful delivery of a product: the Chess Game Evaluator. A Project Manager, like Kasparov, represents a master in Software Engineering. The thrill of succeeding in a formidable project represents the ultimate challenge. This book, like the Blue Machine, wants to challenge you, cooperatively and progressively.
2.3 Principles embedded
The ten principles below will lead you to assert on delivery of the evaluator: "I am ready!" In the next seven chapters, you will experience these principles within the Software Engineering Process Architecture (SEPA).
Figure 9 embeds these principles, coined "POWER-HABIT" (see Appendix A for details) with reference to Barry W. Boehm W5 H4 principle (Who, What, Why, Where, When, How, How Much, How Well, How Soon):
Distributed Project view exploration; Incremental and recursive skill evaluation; Productivity-oriented scenario exploration; Simplicity and generality of process evaluation; Key Process Area exploration; Performance-oriented scenario exploration; Information effectiveness evaluation; Clarity of progressive knowledge exploration; Results-oriented action evaluation; and Quality criteria goal evaluation.
2.4 Life cycle model selected
Five phases coined "Meta Operation" guide you to progressively master the knowledge and skills required from base level, to intermediate, to advanced, and ultimately to expert level. Based on Software Engineering best practices (see Appendix E for details), you can elaborate generic plans that will guide you successfully through your project.
In Phase 1, you demonstrate an ability to perform, experience process patterns and apply generic concepts. In Phase 2, you perform the activities assigned under the current project. Your activities provide the means for a tutor to assess progress and analyze changes. In Phase 3, artifacts generated offer an opportunity to assess quality of work, reliability of product and efficiency of process. In Phase 4, you demonstrate the ability to estimate work and the ability to evaluate the results using the measurements made in Phase 3. In Phase 5, you demonstrate goal setting; you develop plans; you monitor project performance and you assess quality of product.
Checklists could also provide you with a means to assert transition between phases and the level of proficiency achieved (Figure 10). The latter is based on Bloom's Taxonomy (see Appendix F for the application in this book).
The goal of Bloom's Taxonomy is to draw a roadmap for producing software engineers who can rapidly master the skills and knowledge required to develop and manage small to large projects. To achieve this goal, we propose a curriculum to give the user a body of knowledge and skills to establish a balanced coverage of Software Engineering Process activities, their aspects and the artifacts generated.
Specific learning objectives are summarized below and an example of the curriculum progression is presented in Appendix H:
* Awareness of the existence of model; * Awareness of the existence of representations; * Awareness of the existence of methods; * Awareness of the existence of tools; * Awareness of the existence of techniques; * Awareness of the existence of artefacts; * Awareness of the existence of coding standards; * Awareness of the existence of quality factors; and * Awareness of the existence of life cycle models.
Key focus areas:
* Definitions; * Principles; * Concepts; * Models; * Structures; * Demos; * Techniques; * Task driven projects; and, * Unit driven projects;
* Understanding of the Software Engineering Process in the sense of abstract models; * Understanding of the activities and aspects of the process; * Understanding of the issues that are influencing the growth and evolution of Software Engineering; * Understanding a reasonable set of principles, models, representations, tools, techniques, artefacts, standards, metrics, and life cycle models; * Understanding of the role of analysis, design, and evaluation in Software Engineering; and
* Understanding the activities in Software Engineering required for the production of software components under the constraints of control and management activities. Key focus areas: * Software Engineering Process Architecture; * Goals setting; * Key Process Areas; * Common Framework (Meta-Processes); * Key Practices; * Tools & Techniques; and * Artefacts Generation.
* Application of fundamental principles in the performance of the various activities; * Application of best practices in the performance of the various activities; * Application of analysis, design, and evaluation Tools & Techniques for components development; * Application of Formal Methods and V&V techniques to Verify the design; * Application of process and product measurements for Project Management purposes; * Execution of plans, such as Software Development Plan; and * Application of documentation standards and coding standards. Key focus areas: * Specifications; * Documentation; * Model development; * Verification & Validation; * Tools & Techniques; * Software Development Plan development; * Formal Methods; and * Process-driven activities.
* Analysis of customer's system environment; * Analysis of system key actors interactions; * Specification of customer's requirements; * Partitioning of customer's requirements to subsystems and components; * Specification of high level system architecture; * Specification of System Acceptance Test; * Generation of Software Development Plan; * Generation of scenarios and Use Cases; * Inspection, Verification & Validation of artefacts; * Generation of process improvement metrics and indicators; and * Tracking changes and defects.
Key focus areas:
* Process Improvement Specification; * Artefacts inspection, Verification & Validation; * Change and Defect Process Specification; * Subsystem Specification; * User Interface Specification; * Prototyping; and * Goal-Driven activities.
* Conduct component and system performance trade-offs; * Create design baseline; * Develop plans such as the Software Development Plan; * Establish design gates for performance evaluation; * Establish design guidelines for user interaction automation; * Establish design guidelines for performance allocation * Maintain traceability between requirements and design;
* Conduct process verification to ensure process effectiveness; * Track design and test data for change or defect control; and * Lead technical reviews and inspections.
Excerpted from Software Engineering Notebook by Bernard Carrier Gerry Tarum Copyright © 2010 by Bernard Carrier and Gerry Tarum. Excerpted by permission of AuthorHouse. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
3 Cognitive Engineering Process Phases....................20
4 Distributed process Management views....................22
5 Asynchronous Operations Management....................39
6 Concurrent Project Management Approach....................50
7 Executable Prototyping....................59
8 Verification and Qualification system....................70
Appendix A Plan the work....................79
Appendix B Work the plan....................94
Appendix C Plan the measures....................100
Appendix D Work the measures....................107
Appendix E Software Engineering Best Practices....................110
Appendix F Bloom's Taxonomy....................114
Appendix G Career Progression....................117
Appendix H Curriculum Progression....................119
Appendix I Exercises: Cultural Changes....................121
Appendix J Glossary....................131
Appendix K List of Acronyms....................140
References and Bibliography....................143