BACHELOR OF SCIENCE – SCIENCE – INFORMATION INFORMATION TECHNOLOGY
ICS 2302: SOFTWARE ENGINEERING: ENGINEERING: - COURSE OUTLINE
1. Software specification – Definitions of SWE, Other Engineering Disciplines, Data & functional specs, Data Gathering Methods 2. Software Development Methods – SW Process Activities, SW Process Development, SW Process Improvement, Process Management, Framework for SW Process Change 3. Software Development Tools – SDLC, Development Models: - Waterfall, Prototyping, Agile Method, Rapid Application Development, Iterative & Spiral models. 4. Software Design – Design – SW Construction, Design Concepts, Modularity, CASE Tools, Aspects of Object Oriented Programming 5. Software project management – Definition of Terms, Management Context, Process Management, SW Measurements, Total Quality Management 6. Software Estimation Concerns – Costs & Effort Estimation, Estimation Methods:Empirical Models, SLIM, COCOMO 7. Software Metrics – Maintainability, Documentation, Complexity, Reliability, Availability, Comprehensibility 8. Software Testing Techniques - Debugging environments, SW Verification & Validation SW Documentation, SW Configuration Management 9. Software Quality Evaluation – Problems, Software standards, Software maintenance, Certification, Software Tools support for Systems Engineering 10. Software Maintenance - Perfective, Adaptive, Preventive and Corrective maintenance
ASSESSMENT: DELIVERY: LECTURER: COURSE TEXTS 1) 2) 3) 4) 5)
Assignments – Assignments – 2; 2; CATs – CATs – 3; 3; Exam Lectures; Research / Readings; Group Discussions; Case Studies Mr. Musika
[email protected] 0722451338
Software Engineering; Addison Wesley Information systems; Foulks Lynch ltd; 2001 Systems Theory, Theory, Analysis & Design; Riaga Alphonse; 2000 Software Quality Analysis & Guidelines for Success; Casper Casper Jones, 1997 Internet
Page 1 of 61
1. SOTWARE ENGINEERING SPECIFICATIONS 1.1 SWE - DEFINITION is the application of a systematic, disciplined, quantifiable approach to the is Soft Soft ware engi engi neer neer in g development, operation, and maintenance of software; that is, the application of engineering to software. ( IEEE IEEE Computer Society) Society) Soft Soft ware engi engi neer neer in g is the process of solving customers' problems by the systematic is
development and evolution of large-high quality software systems within cost, time, and other constraints (Lethbridge) Software engineering can be described in terms of Analysis - breaking apart a problem into pieces Synthesis - constructing a solution from available or new compon ents. Methods & tools - that enable software projects to be built predictably within proscribed schedules & budgets, meeting the customer's requirements of functionality & reliability. is concerned with the theories, methods and tools which are needed to is Soft Soft ware engi engi neer neer in g develop high quality, complex software in a cost effective way on a predictable schedule. Soft Soft ware engi engi neer neer in g: The disciplined application of engineering, scientific, and mathematical principles, methods, and tools to the economical production of quality software.
Software is abstract and intangible. It is not constrained b y materials, governed by physical laws is
or by manufacturing processes. There are no physical limitations on the potential of software. – software. – of twar e produ ct A softwar consists of developed programs and all associated documentation and consists configuration data needed to make the programs operate correctly. Softwar Soft war e proce pr ocess ss: : The The set of activities, methods, and practices that are used in the production
and evolution of software. Softwar Soft war e proce pr ocess ss model: One specific embodiment of Software process architecture.
: The total set of software engineering activities needed to Softwar e engi neer neer in g proces process transform a user's requirements into software. : A framework within which project-specific software processes Softwar e process process archi ar chi tectu tecturr e are defined.
Levels of Software engineering process 1. 2. 3. 4.
Initial - depends on heroic efforts and skills of key individuals Repeatable - success is predictable for projects in similar application domains. Defined - documented software life cycle model is used for each project Managed - data is collected and analyzed during the project to understand the software life cycle model
Page 2 of 61
5. Optimized - the measurement data used in a feedback mechanism to improve the software life cycle model over the lifetime of the organization. The Nature of Software - Software is an executable specification of a computation / application Soft Soft ware is flexibl e Softwar Soft war e i s expres expr essive sive - All - All computable functions may be expressed in software. Complex event driven systems may be expressed in software. Softwar e is huge hu ge - An operating system may consist of millions of lines of code. - Software - Software has little regularity or recognizable components found in other Softwar e is complex complex complex systems and there are exponentially many paths through the code and changes in one part of the code may have unintended consequences in other equally remote sections of the code. - Manufacturing cost is zero, development cost is ever ything. Thus, the first Softwar e is cheap cheap copy is the engineering prototype, the production prototype and the finished product. Soft Soft ware is neve never fi ni shed - The changing requirements and ease of modification permits the maintenance phase to dominate a software product's life cycle, i.e., the maintenance phase consists of on going design and implementation cycles. Softwar e is eas easilil y modif ied - It is natural to use an iterative development process combining requirements elicitation with design and implementation and use the emerging implementation to uncover errors in design and in the requirements. Soft Soft ware is communi communi cation - Communication with a machine but also communication between the client, the software architect, the software engineer, and the coder. Software must be readable in order to be evolvable.
But software engineering is radically different than other engineering disciplines, in that: The end product is abstract, not a concrete object like a bridge Costs are almost all human; materials are an ever shrinking fraction Easy to fix bugs, but hard to test and validate Software never wears out...but the hardware/Os platforms it runs on do Variations in application domain are open-ended, may require extensive new non software, non-engineering knowledge for each project
Difference with traditional engineering disciplines Software development/engineering: The engineering method Requirements elicitation Formulate the problem Requirement Analysis Analyze the problem System design Search for solutions Object design Decide on the appropriate solution System Implementation Specify the solution
During analysis review, comparison of application domain model with client's reality may result in changes to each. During testing, the system is validated against the solution domain mod el, which might change due to the introduction of new technologies. During project management, managers compare their model of the development process (schedule & budget) against reality (products and resources).
Page 3 of 61
Software life cycle processes Soft ware li f e cycle : The period of time that begins when a software product is conceived and
ends when the software is no longer available for use. This cycle typically includes a Traditional software life cycle phases
Extreme programming
concept phase software development life cycle requirements phase o design phase o implementation phase o test phase o installation and checkout phase o operation and maintenance phase retirement phase
Listening/Planning Designing Testing Coding
These phases overlap and are performed iteratively.
These phases may overlap and/or be performed iteratively.
Project phases for the development for any large system 1. Initial conception 2. Requirements analysis 3. Specification 4. Initial design 5. Verification and test of design 6. Redesign 7. Prototype manufacturing 8. Assembly and system-integration tests 9. Acceptance tests (validation of design) 10. Production (if several systems are required) 11. Field (operational) trial and debugging 12. Field maintenance 13. Design and installation of added features 14. Systems discard (death of system) or complete system redesign. The reasons for increases in cost are: 1. 2. 3. 4. 5.
Testing becomes more complex and costly; Documentation of changes becomes more widespread and costly; Communication of problems and changes involves many people; Repeating of previous tests (regression testing) beco mes costly; Once operation is begun, the development team is disbanded and reassigned.
Page 4 of 61
1.2 DATA GATHERING METHODS Common methods are: Interviewing, Questionnaires, Observation, Repertory Grids, Joint Application Design 1.2.1 INTERVIEWING
An interview is a systematic attempt to collect information from a person. Interviewing is the most widely used technique in requirements engineering. Anal ysts interview future users of the system individually to find out what the present system does and what changes are needed. The information gathered during the interviews enables the analysts to design a new system that will eliminate the shortcomings of the current one. Interviewing is an important skill for systems analysts because success depends on an ability to identify:
Work flows, Factors that influence the operations of systems, and The elements (documents, procedures, policies, etc.) that make up systems.
Without accurate and complete information:
the new system would probably not contain the necessary features to meet the needs of the organization Poorly performed interviews can affect the attitudes of the users and have a negative effect on the entire project effort.
The interview process has five steps:
Preparing for the interview Planning and scheduling the interview Opening and closing the interview Conducting the interview Following up for clarification
Preparing for the Interview Before undertaking an interview the analyst should have a good understanding of the organization, its industry setting, and the project's scope and objectives. This involves reviewing:
organization reports annual reports long-range planning documents statements of departmental goals existing procedure manuals and systems documentation
Page 5 of 61
Analysts must understand common industry terms and be somewhat familiar with the business problems of the industry. The following are errors commonly made by inexperienced analysts:
Sitting back in a chair with arms folded across the chest (This posture implies a lack of openness to what is being said and may also indicate that the analyst is ill at ease.) Looking at objects in the room or staring out the window instead of looking at the interviewee. (Because this behavior suggests that the analyst would rather b e somewhere else doing other things, the interviewee will often cut the interview short.) Taking excessive notes or visually reviewing notes. (An anal yst who records rather than listening may arouse interviewee concerns over what is being written.) Sitting too far away or too close. (Sitting too far away often communicates that the analyst is intimidated by the interviewee, while sitting too close may commun icate an inappropriate level of intimacy and make the interviewee uncomfortable. Acceptance cues are used to convey understanding, not agreement.
Advantages:
Appropriate when the requirements engineer wants to ex plore an issue Facilitates description of domain in a way that is e asy for the interviewee Goal is to establish rapport and to get a broad view Forces an organization on the interview Very goal-directed Attempts to remove distortion from interviewees subjectively Allows better integration of material after the interview Forces the interviewee to be systematic Requirements engineer identifies gaps in the knowledge which acts as a basis for questions Purpose of session is clear to interviewee
Disadvantages:
Data acquired is often unrelated and difficult to integrate Often exhibits lack of structure Does not allow gathering of specific knowledge Takes time and training to do well Similar questions asked in future sessions may annoy interviewee Needs more preparation by the requirements engineer Needs to study background material extensively
1.2.2 JOINT APPLICATION DESIGN (JAD) Joint Application Design (JAD) is a group interview conducted by an impartial leader. The advantages of JAD are that the analysis phase of the life cycle is shortened and the specifications document produced are better accepted by the users.
Page 6 of 61
Requirements analysis should not start until there is a clea r statement of scope and objectives of the project.
Interviewing users to build a physical model of the present system, abstracting this to a logical model of the present system, and then incorporating desirable changes so as to create the logical model of the future system. Organizing a workshop with group methods such as JAD to create the logical model of the new system directly, without the intermediate steps of the ph ysical and logical models of the present system.
The logical model of the new system becomes the requirements specification. Typically, it contains:
An introduction containing the scope, goals, and objectives of the system. Data flow diagrams depicting the workflow of the new system, including the clear identification of business transactions. A project data model (e.g. ER model). Information needs : which types of questions will be asked of th e system and which data will support the answers. Interfaces with other systems. Sample report, screen, and form layouts , if required. Operational information such as processing frequencies and schedules, response time requirements, resource utilization constraints. Measurable criteria for judging the implementation.
The final test of the system, the user acceptance test , should be conducted as a benchmark against this document. Therefore, all those factors that will determine whether the users are satisfied with the system should be documented and agreed upon. There may be a final step in the requirements analysis--to have the users and top man agement sign off on the specification document. There is the need to review the present system before designing a new one, because:
it gives the design team a good grasp of the business problems it lets them understand the environment in which t he new system will operate it helps make sure everything needed is considered it helps to relate the new design to the old one for ease of use it enhances cooperation between project team and users
Page 7 of 61
2. SOFTWARE DEVELOPMENT METHODS SOFTWARE DEVELOPMENT ACTIVITIES
The software process is a set of activities and associated results which produce a software product. The software process is the set of tools, methods, and practices we use to produce a software product. Requi rements elici tation - Client and developers define the purpose of the system, Delivering
Description of the system in terms of actors and use cases. Requi rements An alysis - Developers transform use cases into an object model th at completely
describes the system; Delivering a Model of the system that is correct, complete, consistent, unambiguous, realistic, and verifiable. System design - Developers define the design goals of the project and decomposition of the
system in to smaller subsystems that can be realized b y individual teams. Delivers a Clear description of strategies, subsystem decomposition, and deployment diagram Obj ects design - Developers define custom objects (interfaces, off-the-shelf components, model
restructuring to attain design goals) to bridge the gap between the analysis model and the hardware/software platform defined during system design. Delivers a Detailed object model annotated with constraints and precise descriptions for each element I mplementati on - Developers translate object model into source code; Delivering a Complete set
of source code files.
Software specification - software functionality and constraints Software development - production of the software to meet the specifications. Software validation - ensure software does what the customer wants. Software evolution - ensure the software continues to meet the customer's needs.
The characteristics of an effective software process It must be predictable.
Cost estimates and schedule commitments must be met with reasonable consistency, and the resulting products should generally meet users' functional and quality ex pectations. The objectives of software process management are to produce products according to plan while simultaneously improving the organization's capability to produce better products. The basic principles are those of statistical process control, which have b een used successfully in many fields. A process is said to be stable or under statistical control if its future performance is predictable within established statistical limits.
Page 8 of 61
When a process is under statistical control, repeating the work in roughly the same way will produce roughly the same result. The basic principle behind statistical control is measurement . The numbers (measures) must properly represent the process being controlled, and they must be sufficiently well defined and verified to provide a reliable basis for action. Also, the mere act of measuring human processes changes them. Measurements are both expensive and disruptive ; overzealous measuring can degrade the process we are trying to improve.
Software Process Development The entire software task must be treated as a process that can be controlled, measured, and improved. A process is a set of tasks that, when properly performed, produces the desired result. A fully effective software process must consider the relationships of all the required tasks, the tools and methods used, and the skill, training, and motivation of the people involved. To improve their software capabilities, organizations must take six steps: Understand the current status of their development process. Develop a vision of the desired process. Establish a list of required process improvement actions in order of priority. Produce a plan to accomplish the required actions. Commit the resources to execute the plan. Start over at step 1 . The framework addresses the six improvement steps by characterizing the software process into one of five maturity levels. Software professionals and their managers can identify areas where improvement actions will be most fruitful by establishing their organization's position in this structure. The Five Levels of Software Process Maturity
- Characteristics : Chaotic--unpredictable cost, schedule, and qua lity performance. (1) I niti al Needed Actions : Planning (size and cost estimates and schedules), performance tracking, change control, commitment management, Quality Assurance. (2) Repeatable - Characteristics : Intuitive--cost and quality highly variable, reasonable control
of schedules, informal and ad hoc process methods and procedures. Needed Actions : Develop process standards and definitions, assign process resources, establish methods (requirements, design, inspection, and test). (3) Def in ed - Characteristics : Qualitative--reliable costs and schedules, improving but
unpredictable quality performance.
Page 9 of 61
Needed Actions : Establish process measurements and quantitative quality goals, plans, measurements, and tracking
- Characteristics : Quantitative--reasonable statistical control over product quality. (4) M anaged Needed Actions : Quantitative productivity plans and tracking, instrumented process environment, economically justified technology investments
- Characteristics : Quantitative basis for continued capital investment in process (5) Optimizin g automation and improvement. Needed Actions : Continued emphasis on process measurement and process methods for error prevention.
Software Process Improvement The software maturity framework has been found to reasonably represent the status and key problem areas of many software organizations. As the practice of software evolves, the framework provides a broader perspective on the improvement needs of software organizations. Software process improvement actions are grouped as follows: 1. Organization - This deals with management leadership of software organizations typically
exercised through policies, resource allocation, communications, and training. Policies state the basic principles of organizational behavior. The organization structure establishes basic responsibilities and allocates resources. Management oversight concerns management awareness of organizational performance. Communication deals with the means to ensure available knowledge to support timely action. Training ensures that the software professionals are aware of and c apable of using the pertinent standards, procedures, methods, and tools. 2. Project management - this deal with the normal activities of planning, tracking, project control, and subcontracting. Planning includes the preparation of plans and the operation of the planning system. The tracking and review systems ensure that appropriate activities are tracked against the plan and that deviation are reported to management. Project control provides for control and protection of the critical elements of the software project and its process. Subcontracting concerns the me ans used to ensure that subcontracted resources perform in accordance with established policies, procedures, and standards. 3. Pr ocess man agement - With improving organizational maturity, a process infrastructure is
established to uniformly support and guide the projects' work. Th is involves process definition, process execution, data gathering and analysis, and process control. The process definition provides a standardized framework for task implemen tation, evaluation, and improvement. Process execution defines the methods and techniques used to produce quality products. Analysis deals with the measurements made of software products and p rocesses and the uses made of this data. Process control concerns the establishment of mechanisms to assure the
Page 10 of 61
performance of the defined process and process monitoring and adjustment where improvements are needed. 4. Technology - This topic deals with technology insertion and environments that covers the
means to identify and install needed technolog y, while environments include the tools and facilities that support the management and execution of the defined process.
Process Management The critical steps are: 1. Install a management review system. This involves senior management and ensures that plans are produced, approved, and tracked in an orderly way. 2. Insist on a comprehensive development plan. This must include code size estimates, resource estimates and a schedule. 3. Set up a Software Configuration Management (SCM) function. This is crucial to maintaining control and must be in place and operational before completion of detailed design. These functions should then be expanded to include requirements and design. 4. Ensure that a Software Quality Assurance (SQA) organization is established and sufficiently staffed to review a reasonable sample of the work products. Un til there is evidence that the work is done according to plan, this is essentially a 100% review. With successful experience the sampling percentage can be reduced. 5. Establish rate charts for tracking the plan. Typical milestones are: requirements completed and approved, the operational concept reviewed and approved, high-level design completed and reviewed, percent of modules with detailed design completed, percent of modules through code and unit test. Similar rate charts can be established for each phase of test. MANAGING SYSTEM DEVELOPMENT PROJECT
Principal causes of information system’s project failure.
Insufficient or improper user participation in the systems development process Lack of management support High levels of complexity and risk in the systems development process Poor management of the implementation process Some systems require extensive organizational change
Effective system project management focuses on 4P’s i.e. People : recruiting, selection, performance management, training, compensation, career development, organization and work design and team/ culture development Product : product objective and scope should be established first, alternative solutions considered, parameters established etc. defining the product , therefore it is possible to estimate cost, effectiveness and project breakdown to manageable schedules Process : frame work activities from which a comprehensive plan for system development can be established
Page 11 of 61
Number of framework activities, made up of i.e. tasks, milestone, work products and the project team adapts quality assurance points. Umbrella activities such as quality assurance, system configuration management and measurement lays the process model Project : is planned and controlled system (project) undertaking to achieve a goal/ attain a solution Project is a human activity that achieves a clear objective against a timescale Characteristics: i) Specific objectives to be completed within certain specifications ii) Has a defined time and task schedule iii) Has a defined budget iv) Requires resources such as people v) There is no practice or rehearsal vi) Change: a project commissions change
SOFTWARE PROCESS CHANGE
The six requirements for software process change are: 1. Involve management - Significant change requires new priorities, additional resources, and consistent support. Senior managers will not provide such backing until they are convinced that the improvement program makes sense. 2. Get technical support - This is best obtained through the technical opinio n leaders (those whose opinions are widely respected). When the y perceive that a proposal addresses their ke y concerns, they will generally convince the others. However, when the technical community is directed to implement something they don't believe in, it is much more likely to fail. 3. Involve all management levels - While the senior managers provide the resources and the technical professionals do the work, the middle mana gers make the daily decisions on what is done. When they don't support the plan, their priorities will not be adjusted, and progress will be painfully slow or nonexistent. 4. Establish an aggressive strategy and a conservative plan - While senior management will be attracted by an aggressive strategy, the middle managers will insist on a plan that they know how to implement. It is thus essential to be both aggressive and realistic. The strategy must be visible, but the plan must provide frequent achievable steps toward the strategic goals. 5. Stay aware of the current situation - It is essential to stay in touch with current problems. Issues change, and elegant solutions to last year's problems may no longer be pertinent. While important changes take time, the plan must keep pace with current needs. 6. Keep progress visible - People easily become discouraged if they don't see frequent evidence of progress. Advertise success, periodically reward the key contributors, and maintain enthusiasm and excitement.
Page 12 of 61
SOFTWARE DEVELOPMENT TOOLS
Any System Development is represented by a model called System Development Life Cycle (SDLC) contains 5 stages that flow from one to th e next in order (hence the 'waterfall' imagery). There are alternatives to SDLC that includes, Waterfall model, Prototyping, Iterative Development, Spiral Model of the SDLC etc THE CLASSIC LIFE CYCLE OR WATERFALL MODEL
The following activities occur during the life cycle paradigm:
System Engineering. Top level customer requirements are identified, functional and system interfaces are defined and the relation of this software to ove rall business function is established. Analysis . Detailed requirements necessary to define the function and performance of the software are defined. The information domain for the system is analyzed to identify data flow characteristics, key data objects and overall data structure. Design. Detailed requirements are translated into a series of system representations that depict how the software will be constructed. The design encompasses a description of program structure, data structure and detailed procedural descriptions of the software. Code. Design must be translated into a machine executable form. The coding step accomplishes this translation through the us e of conventional programming languages (e.g., C, Ada, Pascal) or fourth generation languages. Testing. Testing is a multi-step activity that serves to verify that each software componen t properly performs its required function and validates that the system as a whole meets overall customer requirements. Maintenance. Maintenance is the re-application of each of the preceding activities for existing software. The re-application may be required to co rrect an error in the original software, to adapt the software to changes in its ex ternal environment (e.g., new hardware, operating system), or to provide enhancement to fu nction or performance requested by the customer.
This is the most widely used approach to software engineering. It leads to systematic, rational software development, but like any generic model, the life cycle paradigm can be problematic for the following reasons: 1. The rigid sequential flow of the model is rarely en countered in real life. Iteration can occur causing the sequence of steps to become muddled. 2. It is often difficult for the customer to provide a detailed specification of wh at is required early in the process. Yet this model requires a d efinite specification as a necessary building block for subsequent steps.
Page 13 of 61
3. Much time can pass before any operational elements of the system are available for customer evaluation. If a major error in implementation is made, it m ay not be uncovered until much later. Do these potential problems mean that the life cycle paradigm should be avoided? Absolutely not! They do mean, however, that the application of this software engineering paradigm mu st be carefully managed to ensure successful results. PROTOTYPING
Prototyping moves the developer and customer toward a "quick" implementation. Prototyping begins with requirements gathering. Meetings between developer and customer are conducted to determine overall system objectives and functional and performance requirements. The developer then applies a set of tools to develop a quick design and build a working model (the "prototype") of some element(s) of the system. The customer or user "test drives" the prototype, evaluating its function and recommending changes to better meet customer needs. Iteration occurs as this process is repeated, and an acceptable model is derived. The developer then moves to "productize" the prototype by applying many of the steps described for the classic life cycle. In object oriented programming a library of reusable objects (data structures and associated procedures) the software engineer can rapidly create prototypes and production programs. The benefits of prototyping are:
1. A working model is provided to the customer/user early in the process, enabling early assessment and bolstering confidence, 2. The developer gains experience and insight by building the model, thereby resulting in a more solid implementation of "the real thing" 3. The prototype serves to clarify otherwise vague requirements, reducing ambiguity and improving communication between developer and user. But prototyping also has a set of inherent problems: 1. The user sees what appears to be a fully working system (in actuality, it is a partially working model) and believes that the prototype (a model) can be easily transformed into a production system. This is rarely the case. Yet man y users have pressured developers into releasing prototypes for production use that have be en unreliable, and worse, virtually un - maintainable. 2. The developer often makes technical compromises to build a "quick and dirty" model. Sometimes these compromises are propagated into the production system, resulting in implementation and maintenance problems. 3. Prototyping is applicable only to a limited class of p roblems. In general, a prototype is valuable when heavy human-machine interaction occurs, when complex output is to be produced or when new or untested algorithms are to be applied. It is far less beneficial for large, batch-oriented processing or embedded process control applications. ITERATIVE DEVELOPMENT The problems with the Waterfall Model created a demand for a new method of developing
Page 14 of 61
Systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately functions that will be included in the developed s ystem. Prototyping is comprised of the following steps: Requirements Definition /Collection - Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive, the information collected is usually limited to a subset of the complete system requirements Design - Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype. Prototype Creation / Modification - The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding. Assessment - The prototype is presented to the customer for review. Comments and suggestions are collected from the customer. Prototype Refinement - Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient. System Implementation - In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornerstone for the fully functional system. Problems/Challenges associated with the Iterative Model While the Iterative Model addresses many of the problems associated with the Waterfall Model, it does present new challenges. The user community needs to be actively involved throughout the project. While this involvement is a positive for the project, it is demanding on the time of the staff and can add project delay. Communication and coordination skills take center stage in project development. Informal requests for improvement after each phase may lead to c onfusion -- a controlled mechanism for handling substantive requests needs to be developed . The Iterative Model can lead to “scope creep,” since user feedback following each phase may lead to increased customer demands. As users see the system develop, they may realize the potential of other system capabilities which would enhance their work.
Page 15 of 61
THE SPIRAL MODEL The term “spiral” is used to describe the process that is followed as the development of the system takes place. With each iteration around the spiral (beginning at the center and working outward), progressively more complete versions of the system are built. Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost o r lengthened timeframe may make continuation of the project impractical or unfeasible. The Spiral Model is made up of the following steps: Project Objectives - Similar to the system conception phase of the Waterfall Model Objectives are determined, possible obstacles are identified and alternative approaches are weighed Risk Assessment - Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to cla rify needs. Engineering & Production - Detailed requirements are determined and the software piece is developed. Planning and Management - The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer. Problems/Challenges associated with the Spiral Model Due to the relative newness of the Spiral Model, it is difficult to assess its strengths and weaknesses However, the risk assessment component of the Spiral Model provides both developers and customers with a measuring tool that earlier Process Models do not have. The measurement of risk is a feature that occurs everyday in real-life situations, but unfortunately) not as often in the system development industry. The practical nature of this tool helps to make the Spiral Model a more realistic Process Model than some of its predecessors.
Page 16 of 61
REQUIREMENTS ENGINEERING Requirements: the features that the system must have or a constraint that it must satisfy to be accepted by the client - a model of the system that aims to be correct, complete, consistent, and verifiable. Requirements engineering (in the context of systems engineering) is con cerned with the acquisition, analysis, specification, validation, and management of software requirements. Software requirements express the needs and constraints that are placed upon a software product that contribute to the satisfaction of some real world application, alternately, the properties that must be exhibited in order to solve some real world problem. Requirements engineering objective: to elicit that information necessary
to discover how to partition the system; to identify which requirements should be allocated to which components
Requirements elicitation: to systematically extract and inventory the requirements of the system from a combination of human stakeholders, the system's environment, feasibility studies, market analyses, business plans, analyses of competing products and domain knowledge. Stakeholders include Users, Customers, Market analysts, Regulators, System developers Required skills - Technical skills, Ability to acquire an understanding of application domain, Interpersonal skills
Issues For many systems:
Clients do not know what is technically feasible. Clients may change their minds once they see the possibilities more clearly. Knowledge may be tacit (clients may not be able to accurately describe what they do). Discoveries made during the later phases may force retrofitting requirements. There are many social, political, legal, financial, and /or psychological factors. It will be impossible to say with certainty what the requirements are, let alo ne whether or not they are met, until the system is actually in place and running.
CHARACTERISTICS OF REQUIREMENTS
- they gradually emerge from interactions between requirements engineers and the Emergent client organization Open - they are always subject to change because organization and their contexts continually change Local - requirements must be interpreted in the context of a particular organization at a particular time Contingent - because they are an evolving outcome of an on-going processes or builds on prior interactions and documents.
Page 17 of 61
- because they can only be understood in relation to the particular, concrete situation in Situated which it actually occurs. - because they are only elaborated to the degree that it is useful to do so; the rest is left Vague grounded in tacit knowledge. - because they are tied to bodies in particular physical situations, so that the particular Embodied way that bodies are embedded in as situation may be essential to some interpretations Retrospective hypothesis: Only post hoc explanations for situated events can attain relative stability and independence from context. Thus, it is impossible to completely formalize requirements because they cannot be fully separated from their social context.
System requirements are a complex combination of requirements from different people at different levels of an organization and from the environment in which the system must operate.
REQUIREMENTS ELICITATION Requirements elicitation: to systematically extract and inventory the requirements of the system from a combination of human stakeholders, the system's environment, feasibility studies, market analyses, business plans, analyses of competing products and domain knowledge. Corresponds to data collection Activities Identify stakeholders Establish relationships between the development team and the customer Identify actors scenarios use cases; refining use cases relationships among use cases participating objects nonfunctional requirements Resour ce requirements
Goals - the high-level objectives of the system. Must assess the value (relative to priority) and cost of goals.. Domain knowledge System stakeholders The operational environment The organizational environment: business processes conditioned by the structure, culture, and internal politics. El icitation techniques
Users may have difficulty describing their tasks, may leave important information unstated, or may be unwilling or unable to cooperate. Corresponds to the tools and methods for data collection Interviews between requirements team and the client organizatio n structured / unstructured interview, Scenarios, Prototypes, paper mockups, a hastily built software that exhibits the key functionality of the target product, 4GL – SQL, Interpreted languages (Smalltalk, Prolog, Lisp, Java, Unix shell, Hypertext, ...)
Page 18 of 61
TECHNICAL DOCUMENTATION REVIEW Requirements Analysis - is the process of analyzing requirements to: detect and resolve conflicts between requirements, discover the bounds of the system and how it must interact with its environment, During this process elaborate system requirements to software requirements Market analysis Competitive system assessment Reverse engineering Simulations Benchmarking processes and systems
Other considerations include - written by the customers describing things that the s ystem needs to do for them. User Stori es - an example of system use in terms of a series of interactions between the user and the Scenario system. - an abstraction that describes a class of scenarios. Use case Metrics - how rapidly can the client's needs be determined rate of convergence - how frequently the requirements change during the requirements phase
Product and process parameters are requirements on the system which include Product parameters Functional requirements – these are capabilities which are domain specific Non-functional requirements – also referred as constraints or quality requirements which have emergent properties of the interoperation of system components and include Performance, Maintainability, Operational (Installation, Administration, Modifiability) Safety, Reliability and electro-magnetic compatibility requirements - are constraints on the development of the system where the requirements Pr ocess par ameters must be stated clearly, unambiguously, appropriately and quantitatively; avoiding vague and unverifiable requirements that depend on subjective judgment fo r interpretation. - depend on how all the system components inter-operate and are Emergent requir ements dependent on the system architecture. Quali ty r equir ements - should be measurable and prioritized. Requirements Analysis – Concerns classification, Conceptual modeling, Architectural design requirements allocation and negotiation Requirement Specification – is definition document on Software requirements specification (SRS), Document structure, quality and standards Requirements Validation – involves Conducting of requirements reviews, Prototyping, Model validation and Acceptance tests
The tasks involved in the requirements engineering process are iterative and consists of the following
Page 19 of 61
Establish the aims of the project - User needs, Do main information, Standards Repeat 1. Elicit the requirements Informal statement of requirements o 2. Requirements analysis and negotiate trade-offs (budgetary, technical, regulatory, and other) Agreed requirements o 3. Requirements specification Draft requirements document o 4. Requirements validation Requirements document and validation report o Until acceptance of requirements document and validation report
DELIVERABLES Systems Requirements
(Also known as requirements definition document, user requirements document, or concept of operations document - IEEE std 1362-1998) should have the following:
Purpose - Defining high-level system requirements from the stakeholders' perspective; and Serve as a basis for validating the system requirements. Readership/Language - Representatives of the system stakeholders; written in terms of the customer's domain. Contents - Complete list of system requirements having Background information such as: overall objectives for the system, description of the target environment, co nstraints and non-functional requirements. The contents also include: co nceptual models illustrating the system context, usage scenarios, principle domain entities, data, information and workflows Structure – Style which is understandable and consistent
Software Requirements
(Software requirements specification SRS should have; IEEE std 1362-199 8, IEEE std 8301998)
Purpose / content - detailed requirements derived from the system requirements that may form the basis of a contract between developer and customer. Readership/Language - readers have some knowledge of software engineering concepts Structure – style that minimizes effort needed to read and locate information
Page 20 of 61
4. SOFTWARE DESIGN SOFTWARE CONSTRUCTION is a fundamental act of software engineering involving construction of Soft ware constr ucti on working meaningful software through a combination of coding, validation, and testing (unit testing) by a programmer. Design - Description of the internal structure and organization of a system with global solutions expressed as a set of smaller solutions. Construction process – concerns finding a complete and executable solution to a problem Tools - compilers, version control systems, debuggers, code generators, specialized editors, tools for path and coverage analysis, test scaffolding and documentation tools
Distinction between design and construction: 1. Scale or size: very small projects are "construction sized" and neither need or require an explicit o design phase very large project may require an interactive relationship between design and o construction 2. As similar methods are used in design and construction, design is o ften as much construction as it is design. 3. Design will always include some degree of gu essing or approximations that turn out to be wrong and will require corrective actions during construction. Styles of construction - Concerns use of Linguistic construction methods, formal and informal and aims mainly to have Reduction in complexity - Usually complexity in form of: Design patterns Software templates Functions, procedures, code blocks Objects and data structures Encapsulation and abstract data types Component libraries and frameworks
Page 21 of 61
DESIGN CONCEPTS
Three fundamental design concepts are essential to a maintainable system: Modularity - helps to isolate functional elements of the system. One mod ule may be debugged, improved, or extended with minimal personnel interaction or system discontinuity. Specification - The key to production success of any modular construct is a rigid specification of the interfaces; the specification, as a side benefit, aids in the maintenance task by supplying the documentation necessary to train, understand, and provide maintenance. Generality - is essential to satisfy the requirement for extensibility. From this viewpoint, specification should encompass from the innermost primitive functions outward to the generalized functions such as a general file man agement system. Availability - Software components (routines), to be widely applicable to different machines and users should be available in families arranged according to precision, robustness, generality and time-space performance. Software production in the large would be enormously helped by the availability of spectra of high quality routines SOFTWARE DESIGN DOCUMENTATION Need to have a design document providing for Architectural design – A top-level structure and organization of the system being described and various components are identified (how the system is decomposed and organized into components and must describe the interfaces between these components). Implementation design - is sufficiently describing each component to allow for its coding. The programmer - provides creativity and insight into how to solve new, difficult problems, plus the ability to express those solutions with sufficient precision to be meaningful to the computer. The Computer - provides astonishing, reliability, retention, and speed of performance. The implementation - Code that fully and correctly processes data for its entire problem space, anticipates and handles all plausible (and some implausible) classes of errors, runs efficiently, and is structured to be resilient and easy-to-change over time. Programming languages - that have to be of Higher-level and domain specific with features, Functions and procedures, Functional and Logic programming, Concurrent and real-time programming, Program generators, Mathematical libraries and Spreadsheets, OOP (Visual programming and creation of user interfaces)
A programmer should anticipation of diversity and prepare b y having:- Complete and sufficient method sets, OO methods, Table driven software, Configuration files and internationalization, Naming and coding styles, Reuse and repositories, Self-describing software (plug and play),
Page 22 of 61
Parameterization, Generics, Objects and Object classes, Error handling, Extensible frameworks, Visual configuration specification, Separation of GUI design and functionality implementation Structuring for validation – require both Modular design and Structured programming where the programmer Style guides for stepwise refinement that includes:- Assertion-based, State machine logic, Redundant systems with self-diagnosis and fail-safe methods, Hot spot analysis and performance tuning. Also use Numerical analysis that has Complete and sufficient design of OO class methods with Dynamic validation of visual requests
CRITERIA FOR DESIGN LANGUAGE
The criteria that are proposed for the choice of a formal design language are: 1. 2. 3. 4. 5. 6.
It should be easy to learn its basic use. Formulations in the language should be suggestive and thought provoking. It should allow meaningful manipulation of both ex pressions and program segments. It should lead to the development of aesthetic criteria for judging the quality of a design. It should be convenient for documentation. It should be uncommitted to any particular techno logy or problem area. 7. It should be applicable in a consistent way to systems of any foreseeable complex ity. 8. It should be executable on a machine
ASPECTS OF OO PROGRAMMING Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting logical, physical, static and dynamic models of the system under design
The key features of the OO approach and the languages that support it are such that Provide modularity, encapsulation, specification, etc, Provide a design language close to human conceptualization, Allow software manufacturing to be managed more effectively. A language is object-oriented if and only if it satisfies the following requirements:
It supports objects that are data abstractions with an interface of named operations Objects have an associated type [class] Types [classes] may inherit attributes from super-types [ super-classes]
Page 23 of 61
The properties of an Object Oriented Programming Langua ge are:
i) ii)
Abstraction - denotes the essential characteristics of an object that distinguish it from other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer Encapsulation - is the process of hiding all of the details of an object that do not contribute to its essential characteristics Modularity - is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules Hierarchy - is a ranking or ordering of abstractions Typing - is the enforcement of the class of an object, such that objects of different types may not be interchanged, or they may be interchanged only in very restricted ways Concurrency - is the property that distinguishes an active object from one that is not active Persistence - is the property of an object through which its existence transcends time (i.e. the object continues to exist after its creator ceases to exist) and/or space (i.e. the objects location moves from the address space in which it was created)
Object-oriented analysis, design and programming are being p resented as major advances in software engineering. Hardware is of larger magnitude and available memory larger, but our ability to make that hardware perform effectively, and to mana ge this on schedule and to budget is still very poor.
Reasons why we often fail to complete systems with large programs on schedule?
1. Inability to make realistic program design schedules and meet them. For the following reasons: Underestimation of time to gather requirements and define system functions o Underestimation of time to produce a workable (cost a nd time - wise) program design. o Underestimation of time to test individual programs. o Underestimation of time to integrate complete program into the system and complete o acceptance tests. Underestimation of time and effort needed to correct and retest program changes. o Failure to provide time for restructuring program due to chan ges in requirements. o Failure to keep documentation up-to-date. o 2. Underestimation of system time required to perform complex functions. 3. Underestimation of program and data memory requirements. Tendenc y to set end date for job completion and then to try to meet the schedule by attempting to bring more manpower to the job by splitting job into program design blo cks in advance of having defined the overall system plan well enough to define the individual program blocks and their appropriate interfaces.
Page 24 of 61
5. SOFTWARE PROJECT MANAGEMENT DEFI NITI ON OF TERMS the application of management activities that includes: Softwar e engi neer in g management -
planning, coordinating, resource allocation, monitoring, controlling and reporting to insure that the development of software is systematically disciplined and measurable. - involves problem generation, solutions considered, the criteria used to Rati onal e management evaluate the alternatives and the decision makin g process - oversight activities that insure the delivery of a hi gh-quality system on Pr oject management time and within budget including planning, budgeting, hiring and organizing developers into teams establishes baseline, monitors and controls changes in Soft ware conf igu rati on management - work products and versions. - concerns finding differences between the system and its models by executing System Testi ng the system with sample input data sets and includes:o o
o
Unit testing - object design compared with object an d subsystem. Integration testing - combinations of subsystems and comparing them with the system design model. Acceptance testing – delivering accepted system to the users
Software Engineering Management Context Clients often do not appreciate the complexity inherent in software engineering, particularly to the impact of changed client requirements The software engineering process itself will generate the need for new or changed client requirements Software development is an iterative rather than linear process, thus n eed to maintain a balance between creativity and discipline Management to have an underlying theory concerning Software products which are intangible and cannot be easily tested Also the degree of Software complexity and the rapid pace of change in the underlying technology There Is need to carry out management in the following Organizational Management – consideration on Policy, Personnel, Communication, Portfolio and Procurement management Project Management – during the initiation and scope definition, Planning, Enactment, Review, evaluation and Closure of the project
Page 25 of 61
Software Engineering Measurement – issues concerning goals, selection of software and its development, Collection of data, Software measurement mode ls and Organizational comparison Policy management – includes means of policy development, Policy dissemination and enforcement, Development and deployment of standards Personnel management - Hiring and retention, Training and motivation, mentoring for career Development, enhancing Communication channels and media, Meeting procedures, Written, Oral or Negotiation presentations Portfolio management – consideration of multiple clients and/or projects, Strategy development and coordination, General investment management techniques, Project selection and construction Procurement management – involves Procurement planning and selection, Supplier and contract coordination
Process Management Contains the following aspects Initiation and scope definition – considered are Determination and negotiation of requirements, Feasibility analysis (technical, operational, financial, social/political), Process for review and revision of requirements Planning - Process planning, Project planning, Determine deliverables, Effort, schedule and cost estimation, Resource allocation, Risk management, Quality management, Plan management Implementation - Enactment of plans, Implementation of measurement process, Monitor process, Control process, Reporting Review and evaluation - Determining satisfaction of requirements, Reviewing and evaluating performance, Closure - Determining closure and Closure activities PROJECT SCHEDULING
Estimation of time and resources required to complete activities and organization then in a coherent sequence. Involves separating the work (project) into separate activities and judging the time required to complete these activities, some of which are carried out in parallel Schedules must:
Properly co-ordinate the parallel activities properly Avoid situation where whole project is delayed for a critical task to be finished
Page 26 of 61
Schedules must have allowances (error allowances) that can cause delays in completion therefore flexible They must also estimate resources needed to complete each task (human effort, hardware, software, finance (budget) etc) NB: key estimation is to estimate as if nothing will go wrong, then increase the estimate to cover anticipated problems. Also add a further contingency factor to cover the problems. Project schedule is usually presented as a set of charts showing Work breakdown Activity dependency Staff allocation Such charts include: Activity bar charts Activity network chart Gantt charts (staff allocation Vs time chart)
Gantt Charts
A Gantt chart is a horizontal bar chart that illustrates a project task against a calendar. The horizontal position of the bar shows the start and end of the activity, and the length of the bar indicates its duration. For the work in progress the actual dates are shown on the horizontal axis A vertical line indicates a current or reporting date To reduce complexity a Gantt chart for a large project can have a master chart displaying the major activity groups (where each activity represents several task) and is followed by individual Gantt charts that show the tasks assigned to team members. The chart can be used to track and report progress as it presents a clear picture of project status It clearly shows overlapping tasks- tasks that can be performed at that same time The bars can be shaded to clearly indicate percentage completion and project progress Popular due to its simplicity – it is easy to read, learn, prepare and use More effective than PERT/CPM charts when one is seeking to communicate schedules They do not show activity dependencies. One cannot determine from the Gantt chart the impact on the entire project caused by single activity that falls behind schedule. The length of the bar only indicates the time span for completing an activity not the number of people assigned or the person days required
PERT/CPM
Page 27 of 61
Program Evaluation and Review Technique (PERT), (Also Critical Path Method – CPM) is a graphical network model that depicts a project’s tasks and the relationships between those tasks. The project is shown as a network diagram with the activities shown as vectors and events displayed as nodes. Shows all individual activities and dependencies It forms the basis for planning and provides management with the ability to plan for best possible use of resources to achieve a given goal within time and cost limitations It provides visibility and allows management to control u nique programs as opposed to repetitive situations Helps management handle the uncertainties involved in programs by answering such questions as how time delays in certain elements influence othe rs as well as the project completion. This provides management with a me ans for evaluating alternatives It provides a basic structure for reporting information Reveals interdependencies of activities Facilitates hat if exercises It allows one to perform scheduling risk analysis Allows a large amount of sophisticated data to be presented in a well organized diagram from which both the contractor and the customer can make joint decisions Allows one to evaluate the effect of changes in the program More effective than Gantt charts when you want to study the relationships between tasks Requires intensive labour and time The complexity of the charts adds to implementation problems Has more data requirements thus is expensive to maintain Is utilized mainly in large and complex projects Gantt Charts and PERT/CPM are not mutually exclusive techniques project managers often use both methods. Neither handles the scheduling of personnel and allocation of resources
NETWORK ANALYSIS Network analysis is a generic name for a family of related techniques developed to aid management to plan and control projects. It provides planning and control information on time, cost and resource aspects of a project. It is most suitable where the projects are complex, large or restrictions exist. The critical path method is applied most where a network is drawn either an activity on arrow or activity on node network. In the network analysis a project is broken down into consistent activities and their presentation in a diagrammatic form. In the CPM one has to analyze the project, draw the network, estimate the time and cost, locate the critical path, schedule the project, monitor and control the progress of the project and revise the plan.
Example: draw a network and find the critical path for the following project Activity Proceeding Activity Duration A 4 B A 2 C B 10 D A 2
Page 28 of 61
E F G H J K L
D A F G C C, E H
5 2 4 3 6 6 3
ADVANTAGES OF PROJECT MANAGEMENT TOOLS Easier visualization of relationships – a produced network diagram shows how the different tasks and activities relate together making it easier to understand a project intuitively, improving planning and enhancing communication details of the project plan to the interested parties More effective planning – CPM forces the management to think the project through for it requires careful detailed planning and high discipline that justifies its use Better focusing on the problem areas – the technique enables the manager to pin-point likely bottle-necks and problem areas before they can occur Improve resource allocation – resources can be directed where most needed thus reducing costs and speeding up completion of the project, e.g. overtime can be eliminated or confined to those tasks where it will do most good Strong alternative options – management can simulate the effect of alternative causes of action; and gauge the effect of problems in carrying out particular tasks and making contingency plans Management by exception – CPM identifies those actions whose timely completion is critical to the overall timetable and enables the leeway on other actions to be calculated. This enables the management to focus their attention on important areas of the project Improve project monitoring – by comparing the actual performance of each task with the expected the manager can immediately recognize when the problems are occurring, identify their causes and take appropriate action in time to rescue the project.
Importance of project scheduling
The project manager musts know the duration of each activity, the order in which the activities must be performed, the start and end times for ea ch activity, and who will be assigned each specific task. The scheduling allows for a balanced activity time estimate, sequences and personnel assignments to achieve a workable schedule, which is essential for project success The schedule provides: Effective use of estimating processes Ease in project control Ease in time or cost revisions
Page 29 of 61
Allows for better communication of project tasks and deadlines Criteria for defining project success
Completed: i) Within the allocated time ii) Within the budgeted cost iii) At the proper performance or specification level iv) With acceptance by the customer/user v) With minimum or mutually agreed upon scope changes vi) Without disturbing the main work flow of the organization vii) Without changing the corporate culture viii) Within the required quality and standards thus you can use the customer’s name as a reference Potential benefits of project management i) Identification of functional responsibilities to ensure that all activities are accounted for regardless of personnel turnover ii) Minimizing the need for continuous reporting iii) Identification of time limits for scheduling iv) Measurement of accomplishment against plans v) Early identification of problems so that corrective action may follow vi) Improved estimating capability for future planning vii) Knowing when objectives cannot be met or will be exceeded
TOTAL QUALITY MANAGEMENT (TQM)
Based on the work of Dr W Edwards Deming, who is reputed to have transformed Japanese products from shoddy to first in the world, He developed 14 points for management to transform organizations. Consider the following aspects that can be implemented during TQM 1. Create constancy of purpose toward improvement of product a nd service, with the aim to become competitive and to stay in business and to provide jobs. 2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. 3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. 4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, with a long-term relationship of loyalty and trust.
Page 30 of 61
5. Improve constantly and forever the system of production and service, to improve quality and productivity and thus constantly decrease costs. 6. Institute training on the job. 7. Institute leadership. The aim of leadership should be to help people and machines and gadgets to do a better job. Leadership of management is in need of overhau l, as well as leadership of production workers. 8. Drive out fear, so that everyone may work effectively for the company. 9. Break down barriers between departments. People in research, design, sales, and production must work as a team to foresee problems in production and in use that may be encountered with the product or service. 10. Eliminate slogans, exhortations, and targets for the work force that ask for zero defects and new levels of productivity. 11. Eliminate work standards (quotas) on the factory floor. Substitute leadership. Eliminate management by objective. Eliminate management by numbers and numerical goals. Substitute leadership. 12. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from stressing sheer numbers to quality. Remove barriers that rob people in management and engineering of their right to pride of workmanship. This means abolishment of the annual merit rating and management by objective. 13. Encourage education and self- improvement for everyone. 14. Take action to accomplish the transformation.
6. SOFTWARE PROJECT ESTIMATION CONCERNS COST AND EFFORT ESTIMATION Software project managers are responsible for controlling project budgets so, they must be able to make estimates of how much a software development is going to cost. The principal components of project costs are: Computer resources - These include the estimating storage space, pro cessors, terminals, drivers, servers, output media etc. Generally sufficient allowance is given for data growth that involves work files and transaction documents Project overheads - Overheads may include the many supporting activities that form an integral part of the project e.g. assessing technical performance, commitment of personnel, project control, system demonstration, project reviews etc Also considered are Traveling, Training and Effort Costs (e .g. paying software engineers)
PROJECT ESTIMATION
System (software) cost and effort estimate can never be exact, too many variables, human, technical, environmental, political can affect system cost and efforts applied to development The four major tasks undertaken by the project manager when preparing estimates for a given project
Page 31 of 61
Assess the project Identify all the activities Evaluate all the net resource activities Cost the resources Project estimation strive to achieve a reliable cost and effort estimation
A number of options arise trying to achieve this: a) Delay estimation until late in the project (estimates done after the project) b) Base estimates on similar projects that have already been co mpleted c) Use relating simple decomposition technique to generate project cost and effort estimates d) Use one or more empirical models for system cost and effort estimation 1st option is not practical. Estimate must be provided “upfront” 2nd option only works in similar projects 3rd and 4th should be used together to check on one another decomposition techniques take a “divide and conquer approach to project estimation. Project is decomposed (divided) into major functions and related activities and cost and efforts estimated on each. Empirical estimation models: based an experience (historical data) and takes a form D= f(vi) Where d = one of a number of estimated values (e.g. effort, cost, project duration etc) Vi = selected independent parameters (e.g. estimated *LOC o r * FP)
DECOMPOSITION TECHNIQUES - SOFTWARE/ SYSTEM SIZING
Accuracy of system (software) project estimate is predicted on a number of things a) Degree to which the planner has properly estimated the size of the product to be built. b) Ability to translate the size estimate into human efforts, calendar time and money. c) The degree to which project plan reflects the abilities of the system development team d) The ability of product requirements and the environment that supports the system development efforts Project estimate is as good as the estimate of the sizes of the work to be accomplished Size is a quantifiable outcome of the system/ software project
Lines of Code and Function points
Page 32 of 61
QUANTITATIVE MANAGEMENT AND ASSURANCE
Responsibility of quality managers to ensure the required level of quality is achieved Definition – Quality management involves defining appropriate procedures and standards and checking that all engineers (developers) follow them
It depends on developing a “quality culture” System quality is multi-dimensional – the product should meet specifications a) Depending on customer need and wants , as well as the developers needs/ requirements which may not be included in specification b) Some qualities are difficult to measure c) Some specification are incomplete “"Quality is hard to define, impossible to measure and easy to recognize. Definition – “Quality is continually satisfying customer requirements” (Smith 1987) International Standards Organization (ISO) – The totality of features and characteristics of a product or service that bear on the ability to satisfy specified or implied needs (ISO 1986) Garvins view of quality (Garvin 1984) identifies five views of quality a) The transcendent view – Quality is immeasurable but can be seen, sensed or felt and appreciated e.g. art or music b) Product based view – Quality is measured by the attributes/ ingredients in a product c) User based view – Quality is fitness for purpose, meeting needs as specified d) Value based view – the ability to provide the customer with the product/ services they want at the price they can afford.
SOFTWARE COST ESTIMATION The dominant cost is the effort cost. This is the most difficult to estimate and control, and has the most significant effect on overall costs. Software costing should be carried out objectively with the aim of accurately predicting the cost to the contractor of developing the software. Software cost estimation is a continuing activity which starts at the proposal stage an d continues throughout the lifetime of a project. Projects normally have a budget, and continual cost estimation is necessary to ensure that spending is in line with the budget. Effort can be measured in staff-hours or staff-months (Used to be known as man-hours or man-months). Boehm (1981) discusses seven techniques of software cost estimation: (1) Algorithmic cost modeling - A model is developed using historical cost information which relates some software metric (usually its size) to the project cost. An estimate is made of that metric and the model predicts the effort required.
Page 33 of 61
(2) Expert judgement - One or more experts on the software development techniques to be used and on the application domain are consulted. They each estimate the project cost and the final cost estimate is arrived at by consensus. (3) Estimation by analogy - This technique is applicable when other projects in the same application domain have been completed. The cost of a new project is estimated by analogy with these completed projects. (4) Parkinson's Law - Parkinson's Law states that work expands to fill the time available. In software costing, this means that the cost is determined by av ailable resources rather than by objective assessment. If the software has to be delivered in 12 months and 5 people are available, the effort required is estimated to be 60 person-months. (5) Pricing to win - The software cost is estimated to be whatever the customer has available to spend on the project. The estimated effort depends on the customer's budget and not on the software functionality. (6) Top- down estimation - A cost estimate is established by considering the overall functionality of the product and how that functionality is provided by interacting sub-functions. Cost estimates are made on the basis of the logical function rather than the components implementing that function. (7) Bottom- up estimation - The cost of each component is estimated. All these costs are added to produce a final cost estimate.
ESTIMATION METHODS / TOOLS Estimation may be the most difficult task in an entire software project. Almost all software cost estimation is related to human resources. This is different from other engineering disciplines, which have to deal with more physical resources.
Many estimation techniques use some estimate of size, such as · KLOC (Thousands of lines of code) · FP (Function points) · OP (Object points) Estimation techniques for software projects are: · Using historical data · Decomposition techniques · Empirical models · A combination of any or all of the above HISTORICAL DATA Using historical data for estimation is pretty self-explanatory. This method uses track record on previous projects to make estimates for the new project. Main advantage: It is specific to that organization
Page 34 of 61
Main disadvantages: · Continuous process improvement is sometimes hard to factor in · Some projects may be very different than previous ones ALGORITHMIC COST MODELING
Costs are analyzed using mathematical formulae linking costs with metrics. The most co mmonly used metric for cost estimation is the number of lines of source code in the finished system (which of course is not known). Size estimation may involve estimation by analogy with other projects, estimation by ranking the sizes of system components and using a known reference component to estimate the component size or may simply be a question of engineering judgement. Code size estimates are uncertain because they depend on hardware and software choices, use of a commercial database management system etc. An alternative to using code size as the estimated product attribute is the use of `function- points', which are related to the functionality of the software rather than to its size. Function points are computed by counting the following software characteristics:
External inputs and outputs. User interactions. External interfaces. Files used by the system.
Each of these is then individually assessed for co mplexity and given a weighting value which varies from 3 (for simple external inputs) to 15 (for complex internal files). The function point count is computed by multiplying each raw count by the estimated weight and summing all values, then multiplied by the project complexity factors which consider the overall complexity of the project according to a range of factors such as the degree of distributed processing, the amount of reuse, the performance, and so on. Function point counts can be used in conjunction with lines of code estimation techniques. The number of function points is used to estimate the final code size. Based on historical data analysis, the average nu mber of lines of code in a particular language required to implement a function point can be estimated (AVC). The estimated code size for a new application is computed as follows: Code size = AVC x Number of function points The advantage of this approach is that the number of function points can often be estimated from the requirements specification so an early code size prediction can be made. Levels of selected software languages relative to Assembler language
DECOMPOSITION TECHNIQUES For estimation can be one of two types:
Page 35 of 61
Problem-based - Use functional or object decomposition, estimate each object, and sum the result. Estimates either use historical data or empirical techniques. Process-based - Estimate effort and cost for each task of the process, and then sum the result. Estimates use historical data Main advantage: Easier to estimate smaller parts Main disadvantage: More variables involved means more potential errors EMPIRICAL MODELS For estimation uses formulae of the form g = f(x) Where g is the value to be estimated (cost, effort or project duration) and x is a parameter such as KLOC, FP or OP. Most formulae involving KLOC consistently show that there is an almost linear relationship between KLOC and estimated total effort.
Main advantage: Easy to use Main disadvantage: Models are usually derived from a limited number of projects, but are used in a more generalized fashion
SOFTWARE LIFE CYCLE MANAGEMNT (SLIM) SLIM was constructed by the USA army in 1978 to cover projects exceeding 70 KLOC. This Putman’s model assumes that the effort for software development project is distributed similarly to a collection of Raleigh curves, one for each major development activity.
The model is based on empirical studies and relates the size (S), technology factor (C), total project effort in person years (td); thus S = CK 1/3td4/3 The equation allows one to assess the effect of varying delivery date on the total effort needed to complete the project. Thus for a 10%decrease in elapsed time S = CK 1/3td4/3 = CK 1/3(0.9td)4/3 i.e. K’/K = 1.52 a 52% increase in total life cycle effort. Advantages of SLIM Uses linear programming to consider development constraints on both co st and effort Has fewer parameters needed to generate an estimate (over COCOMO) Disadvantages of SLIM Model usually found insufficiency Not suitable for small projects Estimates are extremely sensitive to the technology factor CONSTRUCTIVE COST MODEL COCOMO is probably the most well-known and well-established empirical model. It was first introduced by Barry Boehm in 1981. It has since evolved into a more comprehensive model named COCOMO II. COCOMO II has a variety of formulae · For various stages of the project · For various size parameters (KLOC, FP, object points) · For various types of project teams
Page 36 of 61
COCOMO - Most widely used model for effort and cost estimation and considers a wide variety of factors. Projects fall into three categories: organic, semidetached, and embedded, characterized by their size. In the basic model which uses only source size: There is also an intermediate model which, as well as size, uses 15 other cost drivers. Cost Drivers for the COCOMO Model.
Software reliability Size of application database Complexity Analyst capability Software engineering capability Applications experience Virtual machine experience Programming language expertise Performance requirements Memory constraints Volatility of virtual machine Environment Turnaround time Use of software tools Application of software engineering methods Required development schedule Values are assigned by the manager.
Page 37 of 61
The intermediate model is more accurate than the basic model.
Page 38 of 61
7. SOFTWARE METRICS From a survey of managers and technicians:
quality of external documentation programming language well-defined programming practices availability of tools programmer experience in data processing programmer experience in the functional area effect of project communication independent modules for individual assignment
In an experiment, five programming teams were given g iven a different objective each: When productivity was evaluated each team ranked first in its primary objective. This shows that programmers respond to a goal.
minimum internal memory output clarity program clarity minimum source statements minimum hours
Define Software Metrics as a set of the measures that are considered and are to be incorporated for quality software product These set of Software Metrics and include:Software Maintainability - This is the main programming costs in most installations, and is affected by data structures, logical structure, documentation, diagnostic too ls, and by personnel attributes such as specialization, experience, training, intelligence, motivation. Maintenance includes the cost of rewriting, testing, debugging an d integrating new features. Methods for improving maintainability are:
inspections automated audits of comments test path analysis programs use of pseudo code documentation dual maintenance of source code modularity Structured program logic flow.
Maintainability is "the ease with which changes can be made to satisfy new requirements or to is
correct deficiencies" [Balci 1997] 1997]. Well designed software should be flexible enough to accommodate future changes that will be needed as new requirements come to light. Since maintenance accounts for nearly 70% of the cost of the software life cycle [ Schach 1999] 1999], the importance of this quality characteristic cannot be overemphasized. Quite often the programmer responsible for writing a section of code is not the one who must maintain it. For this reason, the
Page 39 of 61
quality of the software documentation significantly affects the maintainability of the software product. is "the degree with which software adheres to its specified requirements" is Softwar e Corr Cor r ectness ctness [Balci 1997] 1997]. At the start of the software life cycle, the requirements for the software are determined and formalized in the requirements specification document. Well designed software should meet all the stated requirements. While it might seem obvious that software should be correct, the reality is that this characteristic is one of the hardest to assess. Because of the tremendous complexity of software products, it is impossible to perform exhaustive execution based testing to insure that no n o errors will occur o ccur when the software is run. Also, it is important to remember that some products of the software life cycle such as the design specification cannot be "executed" for testing. Instead, these products must be tested with various other techniques such as formal proofs, inspections, and walkthroughs. is "the ease with which software can be reused in dev eloping other software" is Soft Soft ware Reusa Reusabil bil ity [Balci 1997] 1997]. By reusing existing software, developers can create more complex software in a shorter amount of time. Reuse is already a common technique employed in other engineering disciplines. For example, when a house is constructed, the trusses which support the roof are typically purchased preassembled. Unless a special design is needed, the architect will not bother to design a new truss for the house. Instead, he or she will simply reuse an existing design that has proven itself itself to be reliable. In much much the same way, software can be designed to accommodate reuse in many situations. A simple example of software reuse could be the development of an efficient sorting routine that can be incorporated in many future applications. Software Documentation - is one of the items which is said to lead to high maintenance costs. It is not just the program listing with comments. A program librarian must be responsible for the system documentation, but programmers are responsible for the techn ical writing. Other aids may be text editors, and Source Code Control System (SCCS) tool for producing records. Some companies insist that programmers dictate any test or changes onto a tape every day. da y. Software Complexity - is a measure of the resources which must be expanded in developing, maintaining, or using a software product. A large share of the resources is used to find errors, debug, and retest; thus, an associated measure me asure of complexity is the number of software errors. Items to consider under resources are:
time and memory space; man-hours to supervise, comprehend, design, code, test, maintain and change software; number of interfaces; scope of support software, e.g. e. g. assemblers, interpreters, compilers, operating systems, maintenance program editors, debuggers, and other utilities; the amount of reused code modules; travel expenses; secretarial and technical publications support; Overheads relating to support of personnel and s ystem hardware.
Page 40 of 61
Consideration of storage, complexity, and processing time may or may not be considered in the th e conceptualization stage. For example, storage o f a large database might be considered, whereas if one already existed, it could be left until system-specification. Measures of complexity are useful to: 1. 2. 3. 4.
Rank competitive designs and give a "distance" between rankings. Rank difficulty of various modules in order to assign personnel. Judge whether subdivision of a module is nec essary. Measure progress and quality during development.
Software Reliability - Reliability means: issues that related to the design of the product which will operate well for a substantial length of time. a me tric which is the probability of operational success of software. Probabilistic Models can refer to deterministic events (e.g. motor burns out) when it cannot be predicted when they will occur; or random events. The probability space -- the space of all possible occurrences must first be defined, e.g. in a probability model for program error error it is all possible paths in a program. Then the rules for selection are specified, e.g. for each path, combinations of initial conditions and input values. A software failure occurs when an execution sequence containing an error is processed.
Software Reliability Theory is the application of probability theory to the modeling of failures and the prediction of success probability. Thus Software reliability is the probability that the program performs successfully, according to specifications, specifications, for a given time period. The precise statements / Specifications of:
the host machine the operating system and support software the operating environment the definition of success details of hardware interfaces with the machine details of ranges and rates of I/O data The operational procedures.
Errors are found from a system failure, and may be: hardware, software, operator, or unresolved. Time may be divided into:
operating time, calendar time during operation, calendar time during development, man-hours of coding, development, testing, debugging, Computer test times.
Page 41 of 61
Software is repairable if it can be debugged and the errors corrected. This may not be possible without inconveniencing the user, e.g. air-traffic control system. is "the frequency and criticality of software failure, where failure is an Soft ware Reli abil it y unacceptable effect or behavior occurring under permissible operating conditions" [Balci 1997]. The frequency of software failure is measured by th e average time between failures. The criticality of software failure is measured by the average time required for repair. Ideally, software engineers want their products to fail as little as possible (i.e., demo nstrate high correctness) and be as easy as possible to fix (i.e., demonstrate good maintainability). For some real-time systems such as air traffic control or heart monitors, reliability becomes the most important software quality characteristic. However, it would be difficult to imagine a highl y reliable system that did not also demonstrate high correctness and good maintainability. Software availability - is the probability that the program is performing successfully, according to specifications, at a given point in time. Availability is defined as:
1. The ratio of systems up at some instant to the size of the population studied (no. of systems). 2. The ratio of observed uptime to the sum of the uptime and downtime: A = T (up) / (T (up) + T (down)) (of a single system). These measurements are used to:
Quantify A and compare with other systems or goals. Track A over time to see if it increases as errors are found . Plan for repair personnel, facilities (e.g. test time) and alternative service.
If the system is still in the design and developmen t phase then a third definition is used: 1. the ratio of the mean time to failure (uptimes) and the sum of the mean time to failure and the mean time to repair (downtime): A = MTTF / (MTTF + MTTR) Various hypotheses exist about program errors, and seem to be true, but no controlled tests have been run to prove or disprove them: 1. Bugs per line constant. There are fewer errors per line in a high level language. Many types of errors in machine code do not exist in HOL. 2. Memory shortage encourages bugs. Mainly due to programming "tricks" used to squeeze code. 3. Heavy load causes errors to occur. Very difficult to document and test heavy loads. 4. Tuning reduces error occurrences rate. This involves removing errors for a class of input data. If new inputs are needed, new errors could occur, and the system (hardware and software) must be retuned. Further hypotheses about errors:
Page 42 of 61
1. The normalized number of errors is constant. Normalization is the total number of errors divided by the number of machine language instruction. 2. The normalized error-removal rate is constant. These two h ypotheses apply over similar programs. 3. Bug characteristics remain unchanged as debuggin g proceeds. Those found in the first few weeks are representative of the total bug pop ulation. 4. Independent debugging results in similar programs. When two independent debuggers work on a large program, the evolution of the program is such that the difference between their versions is negligible. Many researchers have put forward models of reliability based on measures of the hardware, the software, and the operator; and used them for prediction, comparative analysis, and development control. Error reliability and availability models provide a quantitative measure of the goodness of the software. There are still many unanswered questions. is "the ease with which software can be used on computer configurations Software Portabili ty other than its current one" [Balci 1997]. Porting software to other computer configurations is important for several reasons. First, "good software products can have a life of 15 years or more, whereas hardware is frequently changed at least every 4 or 5 years. Thus good software can be implemented, over its lifetime, on three or more different hardware configurations" [Schach 1999]. Second, porting software to a new computer configuration may be less expensive than developing analogous software from scratch. Third, the sales of "shrink-wrapped software" can be increased because a greater market for the software is available. is "the degree with which software fulfills its purpose without waste of Software Ef fi ciency resources" [Balci 1997]. Efficiency is really a multifaceted quality characteristic and must be assessed with respect to a particular resource such as execution time or storage space. One measure of efficiency is the speed of a program's execution. Another measure is the amount of storage space the program requires for execution. Often these two measures are inversely related, that is, increasing the execution efficiency causes a decrease in the space efficiency. This relationship is known as the space-time tradeoff. When it is not possible to design a software product with efficiency in every aspect, the most important resources of the software are given priority. Software Comprehensibility - This includes such issues as:
high and low-level comments mnemonic variable names complexity of control flow general program type
Sheppard did experiments with professional programmers, types of program (engineering, statistical, nonnumeric), levels of structure, and levels of mnemonic variable names. He found that the least structured program was most difficult to reconstruct (after studying for 25 minutes) and the partially structured one was easiest. No differences were found for mnemonic variable names, or order of presentation of programs.
Page 43 of 61
Summar ize the SW M etr ics as well as the aspects of qual ity assur ance as foll ows
They define a hierarchical software characteristic tree, the arrow indicates logical implication. The lowest level characteristics are combined into medium level characteristics. The lowest level are recommended as quantitative metrics. They define each one. Then they evaluated each by their correlation with program quality, potential benefits in terms of insights and decision inputs for the developer and user, quantifiable, feasibility of automating evaluation. The list is more useful as a check to programmers rather than a guide to program construction. SOFTWARE TESTING
Defect testing - Testing programs to establish the presence of system defects. The goal is to discover defects in programs. A successful defect test is a test which causes a program to behave in an anomalous way. Tests show the presence not the absence of defects Component testing - Testing of individual program components, usually the respon sibility of the component developer (except sometimes for critical systems) Tests are derived from the developer’s experience Integration testing - Testing of groups of components integrated to create a system or subsystem. The responsibility of an independent testing team Tests are based on a system specification Black-box testing - An approach to testing where the program is considered as a ‘black - box’ in that the program test cases are based on the system specification Test data - Inputs which have been devised to test the system Test cases - Inputs to test the system and the predicted outputs from these inputs if the
system operates according to its specification
Page 44 of 61
Testing guidelines
Test software with sequences which have only a single value Use sequences of different sizes in different tests Derive tests so that all the elements of the sequence are accessed White Box Testing - also referred to as Structural testing and it is a de rivation of test cases according to program structure, where Knowledge of the program is used to identify additional test cases especially ascertaining the conditions and elements of arra ys Path testing - The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once. The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control Top-down testing - Starts with high-level system and integrate from the top-downwards replacing individual components by stubs where appropriate Bottom-up testing - Integrate individual components in the various levels until the complete system is created.
NB. In practice, most of testing approaches involves a combination of these strategies Interface testing - Takes place when modules or sub-systems are integrated to create larger systems. Objectives are to detect faults due to interface errors or invalid assumptions abou t interfaces. Particularly important for object-oriented development as objects are defined by their interfaces Interfaces types Parameter interfaces - Data passed from one procedure to another Shared memory interfaces - Block of memory is shared between procedures Procedural interfaces - Sub-system encapsulates set of procedures to b e called by other systems Message passing interfaces - Sub-systems request services from other sub-systems Stress testing - Stress testing checks for unacceptable loss of service or data. Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded. Stressing the system often causes defects to be revealed. Object-oriented testing - The components to be tested are object classes that are instantiated as objects an extension of white-box testing. Scenario-based testing - Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario
Page 45 of 61
SOFTWARE VERIFICATION AND VALIDATION
Verification and Validation are concerned with assuring that a software system meets a user's needs Validation: validation shows that the program meets the customer’s needs. The software should do what the user really requires. The designers are guided by the notion of whether they are building the right product Verification: Verification shows conformance with specification. The software should conform to its functional specification. The designers are guided by the notion whether they are building the product right Static and dynamic verification Static verification on Software inspections is concerned with analysis of the static system representation to discover problems within software product based on document and code analysis Dynamic Veri fi cation - concerns Software testing with exercising and observing product
behaviour where the system is executed with test data and its operational behaviour is observed
Program testing – is done to reveal the presence of errors NOT their absence. A successful test is a test which discovers one or more errors. The only validation technique for non -functional requirements
Verification and validation should establish confidence that the software is fit for purpose it is designed for. This does NOT mean completely free of defects rather, it must be good enough for its intended use which determines the degree of confidence needed. Depends on system’s purpose, user expectations and marketing environment Software function – concerned with the level of confidence depends on how critical the software is to an organisation User expectations - Users may have low expectations of certain kinds o f software Marketing environment - Getting a product to the market early which may be more important than finding defects in the program SOFTWARE TESTING
Definition 2 - Testing involves actual execution o f program code using representative test data sets to exercise the program and outputs are examined to detect any deviation from the expected output
Page 46 of 61
Definition 1- Testing is classified as dynamic verification and validation activities Reviews can be applied to: Requirement specifications High level system designs Detailed designs Program code User documentation Operation of delivered system
Objectives of Testing
1. To demonstrate the operation of the software. 2. To detect errors in the software and therefore: Obtain a level of confidence, Produce measure of quality.
THE TESTING PROCESS
Systems in this case are tested, as a single unit therefore testing should proceed in stages, where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of 5 stages: (a) Unit testing (b) Module testing (c) Sub-system testing (d) System testing (e) Acceptance (alpha) testing. (A) UNIT TESTING Unit testing is where individual components are tested independently to ensure they operate correctly. (B) MODULE TESTING A module is a collection of dependent components e.g. an object class, an abstract data type or collection of procedures and functions. Module testing is where related components (modules) are tested without other system modules. (C) SUB-SYSTEM TESTING Sub-systems are integrated to make up a system. Sub-system testing aims at finding errors of unanticipated interactions between sub-systems and system components. Sub-system testing also aims at validating that the system meets the functional and non-functional components. (D) ACCEPTANCE TESTING (ALPHA TESTING)
Page 47 of 61
Acceptance testing is also known as alpha testing or last testing. In this case the system is tested with real data (from client) and not simulated test data. Acceptance testing: Reveals errors and omissions in systems requirements definition. Test whether the system meets the users’ needs or if the system performance is acceptable. Acceptance testing is carried out till users /clients agree it’s an acceptable implementation of the system. N/B 1:Beta testing Beta testing approach is used for software to be marketed. It involves delivering it to a number of potential customers who agree to us e it and report problems to the developers. After this feedback, it is modified and released a gain for another beta testing or general use. N/B 2: The five steps of testing are based on incremental system integration i.e. (Unit testing – module testing – sub-system testing - system testing- acceptance testing). But o bject oriented development is different and levels have clear/ distinct Operations and data forms objects – units Object integrated forms class (equivalent to) – modules Therefore class testing is cluster testing.
TEST PLANNING
Test planning is setting out standards for the testing process rather than describing product tests. Test plans allow developers get an overall picture of the system tests as well as ensure required hardware, software, resources are available to the testing team. Components of a test plan: Testing process This is a description of the major phases of the testing process. Requirement traceability This is a plan to test all requirements individually. Testing schedule This includes the overall testing schedule and reso urce allocation. Test recording procedures This is the systematic recording of test results. Hardware and software requirements. Here you set out the software tools required and hardware utilization. Constraints This involves anticipation of hardships /drawbacks affecting testing e.g. staff shortage should be anticipated here. N/B - Test plan should be revised regularly.
Page 48 of 61
TESTING STRATEGIES
This is the general approach to the testing process. There are different strategies depending on the type of system to be tested and development process used: Top-down testing This involves testing from most abstract component downwards. Bottom-up testing This involves testing from fundamental components upwards. Thread testing This is testing for systems with multiple processes where the processing of transactions threads through these processes. Stress testing This relies on stressing the system by going beyond the specified limits therefore testing on how well it can cope with overload situations. Back to back testing It is used to test versions of a system and compa re the outputs. N/B- Large systems are usually tested using a mixture of strategies.
Top-down testing
Tests high levels of a system before testing its detailed components. The program is represented as a single abstract component with sub-components represented by stubs. Stubs have the same interface as the component, but limited functionality. After top-level component (the system program) is tested. Its sub-components (sub-systems) are implemented and tested through the same way and continues to the bottom component (unit). If top-down testing is used: - Unnoticed errors maybe detected early (structured errors) - Validation is done early in the process. Di sadvantages of U sin g Top down Testi ng
1. It is difficult to implement because: Stubs are required to simulate lower levels of the system. Complex compon ents are impractical to produce a stub that can be tested correctly. Requires knowledge of internal pointer representation 2. Test output is difficult to observe. Some higher levels do not generate output therefore must be forced to do so e.g. (classes) therefore create an artificial environment to generate test results. N/b therefore it is not appropriate for object oriented systems but individual systems may be tested.
Bottom-up testing This is the opposite of top-down testing. This is testing modules at lower levels in the hierarchy, then working up to the final level. Advantages of bottom up are the disadvantages of top-down. + 1. Architectural faults are unlikely to be discovered till muc h of the system has been tested.
Page 49 of 61
2. It is appropriate for object oriented systems because individual objects can be tested using their own test drivers, then integrated and collectively tested.
Thread testing (transaction flow testing-by Bezier 1990)
This is for testing real time systems. It is an event-based approach where tests are based on the events, which trigger system actions. It may be used after objects have been individually tested and integrated into sub-system. -Processing of each external event “threads” its way through the system processes or objects with processing carried out at each stage It involves identifying and executing each possible processing thread. The system should be analyzed to identify as many threads as possible. After each thread has been tested with a single event, processing of multiple events of same type should be tested without events of any other type (multiple-input thread testing). After multiple-input thread testing, the system is tested for its reaction’s to more than one class of simultaneous event i.e. multiple thread testing.
Page 50 of 61
SOFTWARE MAINTENACE
Definition 1 - Maintenance is the process of changing a system after it has been delivered and is in use. Simple - correcting coding errors Extensive - correcting design errors. Enhancement- correcting specification errors or accommodate new requirements. Definition 2 -
Maintenance is the evolution i.e. process of changing a system to maintain its ability
to survive. The maintenance stage of system development involves a) correcting errors discovered after other stages of system development b) improving implementation of the system units c) enhancing system services as new requirements are perceived Information is fed back to all previous development phases and errors and omissions in original software requirements are discovered, program and design errors found and need for new software functionality identified. TYPES OF SOFTWARE MAINTENANCE
The following are the different types of maintenance: Corrective maintenance - This involves fixing discovered errors in software (Coding errors, design errors, requirement errors) once the software is implemented and is in full operation, it is examined to see if it has met the objectives set out in the original specifications. Unforeseen problems may need to be overcome, and may involve returning to the earlier stages in the system development life cycle to take corrective actions Adaptive maintenance - This is changing the software to operate in a different environment (operating system, hardware) this doesn’t radically change the software functionality. After running the software for some time, the original environment e.g. operating System and the peripherals, for which the software was developed, may change. At this stage the software will be modified to accommodate the changes that will have occurred in its external environment. This could even call for a repeat of the system development life cycle yet again Perfective maintenance - Implementing new functional or non-functional system requirements, generated by software customers as their organization or business changes. Also as the software is used, the user will recognize additional functions that could provide benefits or enhance the software if added to it Preventive maintenance - Making changes on software to prevent possible problems or difficulties (collapse, slow down, stalling, self-destructive e.g. Y2K).
Operation stage involves use of documentation to train users of system and its resource system configuration
Page 51 of 61
repairs and maintenance safety precautions date control Train user to get help on the system.
Maintenance cost (fixing bugs) is usually higher than what software is original due to: I. Program being maintained may be old, and not consistent to modern software engineering techniques. They may be unstructured and optimized for efficiency rather than understandability. II. Changes made may introduce new faults, which trigger further change requests. This is mainly since complexity of the system may make it difficult to assess the effects of a change. III. Changes made tend to degrade system structure, making it harder to understand and make further changes (program becomes less cohesive.) IV. Loss of program links to its associated documentation therefore its documentation is unreliable therefore need for a new one.
Factors affecting maintenance Module independence - Use of design methods that allow easy change through concepts such as functional independence or object classes (where one can be maintained independently) Quality of documentation - A program is easier to understand when supported by clear and concise documentation. Programming language and style - Use of a high level language and adopting a consistent style through out the code. Program validation and testing - Comprehensive validation of system design and program testing will reduce corrective maintenance. Configuration management - Ensure that all system documentation is kept consistent through out various releases of system (documentation of new editions.) Understanding of current system and staff availability - Original development staff may not always be available. Undocumented code can be difficult to understand (team management). Application domain - Clear and understood requirements. Hardware stability – concerns for the equipment to be fault tolerant Dependence of program on external environment
SOFTWARE MAINTENANCE PROCESS
Page 52 of 61
Maintenance process is triggered by (a) A set of change requests from users, management or customers. (b) Cost and impact of the changes are assumed, If acceptable, (c) New release is planned involving maintenance elements (adaptive, corrective perfective..) NB. Changes are implemented and validated and new versions of system released.
SOFTWARE CONFIGURATION MANAGEMENT Software configuration is a collection of the items that comprise all information produced as part of the software process. The output of software process is information and includes PC programs, documentation and the data (in its program and external to it). Software Configuration Management Definition 1 These are a set of activities that are developed to manage change through out the life cycle of PC software. Changes are caused by the following: New customer needs New business / market conditions and rules Budgetary or scheduling constraints etc Reorganization or restructuring of business for growth Definition 2 The process which controls the changes made to a system, and manages the different versions of the evolving software product. It involves development and application of procedures and standards for managing an evolving system product. Procedures should be developed for building system releasing them to customers Standards should be developed for recording for recording and processing proposed system changes and identifying and storing different versions of the system. Configuration managers (team) are responsible for controlling software changes. Controlled systems are called baselines. They are the starting point for controlled evolution.
Software may exist in different configurations (versions). produced for different computers (hardware) produced for different operating system produced for different client-specific functions etc Configuration managers are responsible for keeping track of difference between software versions and ensuring new versions are derived in a controlled way. Are also responsible for ensuring that new versions are released to the correct customers at the appropriate time Configuration management and associated documentation should be based on a set of standards, which should be published in configuration management hand book (or quality handbook) E.g. IEEE standards 8238-1983 which is standard for configuration management plans.
Page 53 of 61
Main configuration management’s activities: 1. Configuration management planning (planning for product evolution) 2. Managing changes to the systems 3. Controlling versions and releases (of systems) 4. Building systems from other components Benefits of effective configuration management
Better communication among staff Better communication with the customer Better technical intelligence Reduced confusion for changes Screening of frivolous changes Provides a paper trail
Configuration Management and Planning Configuration management and planning takes control of the systems after they have been developed therefore planning the process must start during development. The plan should be developed as part of overall project planning process. The plan should include: (a) Definitions of what entities are to be managed and formal scheme for identifying these entities. (b) Statement of configuration management team. (c) Configuration management policies for change and version control / management. (d) Description of the tools to be used in configuration management and the process to be used. (e) Definition of the configuration database which will be used to record configuration information. (Recording and retrieval of project information.) (f) Description of management of external information (g) Auditing procedures. Configuration database is used to record all relevant information relating to configuration to: a) assert with assessing the impact of system changes b) Provide management information about configuration management. Configuration database defines/describes Customers who have taken delivery of a particular version Hardware and software operating system requirements to run a given version. The number of versions of system so far made and when they were made etc
CONFIGURATION MANAGEMENT TOOLS Configuration Management – CM- is a procedural process so it can be modelled and integrated with a version management system
Page 54 of 61
Configuration Management processes are standardised and involve app lying pre-defined procedures so as to manage large amounts of data Configuration Management tools F orm editor - to support processing the change request forms Wor kf low system - to define who does what and to automate information transfer that manages change proposals and is linked to a VM system Change database - Version and r elease identi fi cation - Systems assign identifiers automatically when a new version is submitted to the system - System stores the differences between versions rather than all the Storage management version code Change hi story r ecordin g - Record reasons for version creation - Only one version at a time may be checked out for change or I ndependent development Parallel working on different versions CASE TOOLS FOR CONFIGURATION MANAGEMENT Computer Aided Software Engineering (CASE) tools support for CM is therefore essential and are available ranging from stand-alone tools to integrated CM workbenches CASE Tools is a software package that supports c onstruction and maintenance of a logical system specification model Designed to support rules and interactions of models defined in a specific methodology Also permit software prototyping and code generation Aim to automate document production process by ensuring automation of analysis and design operations ADVANTAGES OF CASE TOOLS Make construction of the various analysis and design logical elements easy e.g. DFD, ERM etc Integration of separate elements allowing software to do additional tasks e.g. rechecking and notifying on defined data and programs Streamline the development of the analysis documentation allowing for use of graphics and manipulation of the data dictionaries Allow for easy maintenance of specifications which in turn will be more reliably updated Enforce rigorous standards for all developers and projects making commun ication more efficient Check specifications for errors, omissions and inconsistencies Provide everyone on the project team with easy access to the latest updates and project specifications Encourage iterative refinements resulting to higher quality system that better meets the needs of the users DISADVANTAGES CASE products can be expensive CASE technology is not yet fully evolved so its software is often large and inflexible Products may not provide a fully integrated development environment There is usually a long time for learning before the tools can be effectively used i.e. no soon benefits realized
Page 55 of 61
Analysts must have a mastery of the structured analysis and design te chniques if they are to exploit CASE tools Time and cost estimates may have to be inflated to allow for an extended learning period of CASE tools
PROGRAM EVALUATION DYNAMICS
Program evolution is the study of system change Lehman’s Laws (by Lehman Beladay 1985) about system change. The Laws are: a) Law of Continuing change - Program used in real world environment must change or become progressively less useful in the environment. b) Law of Increasing complexity - Program changes make its structure more complex therefore extra resources must be devoted to preserving and simplifying the structure. c) Law of Large program evolution - Program evaluation in self-regulating process. d) Law of Organization stability - In a program lifetime its rate of development is approximately constant and independent of resources devoted to system development. e) Law of Conservation familiarity - Over the system lifetime the incremental change in each release is approximately constant
SOFTWARE ENGINEERING DOCUMENTATION
It is a very important aid to maintenance engineers. Definition - It includes all documents describing implementation of the system from requirements specification to final test plan. The documents include: Requirement documents and an associated rationale System architecture documents Design description Program source code Validation documents on how validation is done Maintenance guide for possible /known problems. Documentation should be Clear and non-ambiguous Structured and directive Readable and presentable Tool-assisted (case tools) in production (automation). SYSTEM DOCUMENTATION Items for documentation to be produced for a software product include:System Request – this is a written request that identifies deficiencies in the current system besides requesting for change
Page 56 of 61
Feasibility Report – this indicates the economic, legal, technical and operational feasibility of the proposed project Preliminary Investigation Report – this is a report to the management clearly specifying the identified problems within the system and what further action to b e taken is also recommended System Requirements report – this specifies the entire end – user and management requirements, all the alternatives plans, their costs and the recommendations to the management System Design Specification – it contains the designs for the inputs, outputs, program files and procedures User Manual – it guides the user in the implementation and installation of the information system Maintenance Report – a record of the maintenance tasks done Software Code – this refers to the code written for the information system Test Report – this should contain test details e.g. sample test data and results etc Tutorials - a brief demonstration and exercise to introduce the user to the working of the software product SOFTWARE DOCUMENTATION The typical items included in the software documentation are Introduction – shows the organization’s principles, abstracts for other sections and notation guide Computer characteristics – a general description with particular attention to ke y attributes and summarized features Hardware interfaces – a concise description of information received or transmitted by the computer Software functions – shows what the software must do to meet requirements, in various situations and in response to various events Timing constraints – how often and how fast each function must be performed Accuracy constraints – how close output values must be ideal to expected values for them to be acceptable Response to undesired events – what the software must do in events e.g. sensor goes down, invalid data etc Program sub-sets – what the program should do it if it cannot do everything Fundamental assumptions – the characteristics of the program that will stay the same, no matter what changes are made Changes – the type of changes that have been made or are expected Sources – annotated list of documentation and personnel, indicating the types of questions each can answer Glossary – most documentation is fraught with acronyms and technical terms
9. SOFTWARE QUALITY EVALUATION
Page 57 of 61
This concerns identifying key issues or measures that should show where a program is deficient. Managers must decide on the relative importance of:
On-time delivery of the software product Efficient use of resources e.g. processing units, memory, peripheral devices etc Maintainable code issues e.g. comprehensibility, modifiability, portability etc
Problem areas cited software production include
1. User demands for enhancements, extensions 2. Quality of system documentation 3. Competing demands on maintenance personnel time 4. Quality of original programs 5. Meeting scheduled commitments 6. Lack of user understanding of system 7. Availability of maintenance program personnel 8. Adequacy of system design specifications 9. Turnover of maintenance personnel 10. Unrealistic user expectations 11. Processing time of system 12. Forecasting personnel requirements 13. Skills of maintenance personnel 14. Changes to hardware and software 15. Budgetary pressures 16. Adherence to programming standards in maintenance 17. Data integrity 18. Motivation of maintenance personnel 19. Application failures 20. Maintenance programming productivity 21. Hardware and software reliability 22. Storage requirements 23. Management support of system 24. Lack of user interest in system
Quali ty Assur ance
Quality management System -
relevant procedures and standards to be followed Quality Assurance assessments to be carried out
-
Relevant procedures and standards are followed Relevant deliverables are produced
Definition – controls to that
Page 58 of 61
Software quality assurance techniques: The quality and reliability of software can be improved by using A standard development methodology Software metrics Thorough testing procedures Allocating resources to put more emphasis on the analysis and design stages of systems development. Standards specification to be applied during development enforces Quality of products. The specifications should include Quality Assurance (QA) standards to be adopted, which should be of one of the recognized standards or clients specified ones e.g. Correctness - ensures the system operates correctly and provides the value to its user and performs the required functions therefore defects must be fixed/ corrected Maintainability - is the ease with which system can be corrected if an error is encountered, adept if its environment changes or enhance if the user desires a change in requirements Integrity - is the measure of the system ability to withstand attacks (accidental or intentional) to its security in terms of data processing, program performance and d ocumentation Usability - is the measure of user friendliness of a system as measured in terms of physical and intellectual skills required to learn the system, the time required to become moderately efficient in using it, the net increase in productivity if used by moderately efficient user, and the general user attitude towards the system.
System Quality can be looked at in two ways: Qual it y of design – is the characteristic the designers specify for an item/ product. The grade of the materials, tolerance and performance specifications Quali ty of conformance - The degree to which the design specification are followed during development and construction (implementation) QUALITY ASSURANCE Since quality should be measurable, then quality assurance needs to be put in place Quality Assurance consists of Auditing and reporting functions of the mana gement Quality Assurance must outline the standards to be adopted i.e. either International recognized standards or client designed standards Quality Assurance must lay down the working procedure to be adopted during project lifetime, which includes:
Design and Program reviews Program monitoring and reporting Quality Assurance related procedure Test procedure and Fault reporting Delivery and Liaison mechanisms
Page 59 of 61
Safety aspects and Resource usage
Quality Assurance system should be managed independently of development and production departments and clients should have a right to access the contractors Quality Assurance System and Plan Quality Assurance builds clients confidence (increase acceptability) as well as contractors own confidence in knowing that they are building the right system and that it will be highl y acceptable Testing and error correction assures system will perform as expected without defects or collapse and also ensures accuracy and reliability. POOR QUALITY SYSTEM
High cost of maintenance and correcting errors (unnecessary maintenance) Low productivity due to poor performance Unreliability in terms of functionalities Risk of injury to safety critical systems (e.g. robots) Loss of business due to errors Lack of confidence to (in) the developers by clients.
PROFESSIONAL ISSUES IN SYSTEMS DEVELOPMENT
System development is a profession and belongs to the engineering discipline that employs scientific methods in solving problems and providing solutions to the society. Profession is an employment (not mechanical), that require some degree of learning, a calling, habitual employment is a collective body of persons engaged in any profession
The main professional task in system development is on management of the tasks, with an aim of producing system that meets users’ needs, on time and within budget. Therefore main concerns of the management are: - Planning, Progress monitoring and Quality control There are a number of tasks carried out in an engineering organization and are classified into their function: Production - activities that directly contribute to creating products and services the organization sells - activities necessary to ensure the quality of products / services maintained Qual it y management at this agreed level Research an d development - ways of creating / improving products and production process Sales and M ark etin g - selling products / services and involves activities such as advertising, transporting, distribution etc
Page 60 of 61
