Overview SOFTWARE ENGINEERING Overview.

Overview SOFTWARE ENGINEERING Overview

Typical Classical Phases
Requirements phase Explore the concept Elicit the client’s requirements Analysis (specification) phase Analyze the client’s requirements Draw up the specification document Draw up the software project management plan “What the product is supposed to do”

Typical Classical Phases (contd)
Design phase Architectural design, followed by Detailed design “How the product does it” Implementation phase Coding Unit testing Integration Acceptance testing

Typical Classical Phases (contd)
Postdelivery maintenance Corrective maintenance Perfective maintenance Adaptive maintenance Retirement

No separate documentation phase
Documentation activities must be performed in parallel with all other development and maintenance activities There is no separate documentation phase

Strengths of the Object-Oriented Paradigm
With information hiding, postdelivery maintenance is safer The chances of a regression fault are reduced Development is easier Objects generally have physical counterparts This simplifies modeling (a key aspect of the object-oriented paradigm)

Strengths of the Object-Oriented Paradigm (contd)
Well-designed objects are independent units Everything that relates to the real-world object being modeled is in the object — encapsulation Communication is by sending messages This independence is enhanced by responsibility-driven design (see later)

Strengths of the Object-Oriented Paradigm (contd)
A classical product conceptually consists of a single unit (although it is implemented as a set of modules) The object-oriented paradigm reduces complexity because the product generally consists of independent units The object-oriented paradigm promotes reuse Objects are independent entities

Classical Phases vs Object-Oriented Workflows
There is no correspondence between phases and workflows Figure 1.8

In More Detail Objects enter here Figure 1.9

Object-Oriented Paradigm
Modules (objects) are introduced as early as the object-oriented analysis workflow This ensures a smooth transition from the analysis workflow to the design workflow The objects are then coded during the implementation workflow Again, the transition is smooth

The Object-Oriented Paradigm in Perspective
The object-oriented paradigm has to be used correctly All paradigms are easy to misuse When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm

Moving Target Problem A change in the requirements while the software product is being developed Even if the reasons for the change are good, the software product can be adversely impacted Dependencies will be induced Any change made to a software product can potentially cause a regression fault A fault in an apparently unrelated part of the software

Moving Target Problem (contd)
If there are too many changes The entire product may have to be redesigned and reimplemented Change is inevitable There is no solution to the moving target problem

Iteration and Incrementation
In real life, the operations of the analysis phase are spread out over the life cycle The basic software development process is iterative Each successive version is intended to be closer to its target than its predecessor

Miller’s Law At any one time, we can concentrate on only approximately seven chunks (units of information) To handle larger amounts of information, use stepwise refinement Concentrate on the aspects that are currently the most important Postpone aspects that are currently less critical Every aspect is eventually handled, but in order of current importance This is an incremental process

Other Life-Cycle Models
The following life-cycle models are presented and compared: Code-and-fix life-cycle model Waterfall life-cycle model Rapid prototyping life-cycle model Extreme programming and agile processes Synchronize-and-stabilize life-cycle model Spiral life-cycle model

Code-and-Fix Model No design No specifications
Maintenance nightmare The easiest way to develop software The most expensive way Figure 2.7

Waterfall Model Figure 2.8

Rapid Prototyping Model
Linear model “Rapid” Figure 2.9

Extreme Programming Somewhat controversial new approach
Stories (features client wants) Estimate duration and cost of each story Select stories for next build Each build is divided into tasks Test cases for a task are drawn up first Pair programming Continuous integration of tasks

Unusual Features of XP The computers are put in the center of a large room lined with cubicles A client representative is always present Software professionals cannot work overtime for 2 successive weeks No specialization

Synchronize-and Stabilize Model
Microsoft’s life-cycle model Requirements analysis — interview potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in parallel

Synchronize-and Stabilize Model (contd)
At the end of the day — synchronize (test and debug) At the end of the build — stabilize (freeze the build) Components always work together Get early insights into the operation of the product

Spiral Model Simplified form
Rapid prototyping model plus risk analysis preceding each phase If all risks cannot be mitigated, the project is immediately terminated Figure 2.10

Analysis of the Spiral Model
Strengths It is easy to judge how much to test No distinction is made between development and maintenance Weaknesses For large-scale software only For internal (in-house) software only

Comparison of Life-Cycle Models
Different life-cycle models have been presented Each with its own strengths and weaknesses Criteria for deciding on a model include: The organization Its management The skills of the employees The nature of the product Best suggestion “Mix-and-match” life-cycle model

The Unified Process The Unified Process is not a series of steps for constructing a software product No such single “one size fits all” methodology could exist There is a wide variety of different types of software The Unified Process is an adaptable methodology It has to be modified for the specific software product to be developed UML is graphical A picture is worth a thousand words

The Unified Process (contd)
UML diagrams enable software engineers to communicate quickly and accurately The Unified Process is a modeling technique A model is a set of UML diagrams that represent various aspects of the software product we want to develop UML stands for unified modeling language UML is the tool that we use to represent (model) the target software product

The Requirements Workflow
The aim of the requirements workflow To determine the client’s needs First, gain an understanding of the application domain (or domain, for short) That is, the specific business environment in which the software product is to operate Second, build a business model Use UML to describe the client’s business processes If at any time the client does not feel that the cost is justified, development terminates immediately

The Analysis Workflow The aim of the analysis workflow
To analyze and refine the requirements Why not do this during the requirements workflow? The requirements artifacts must be totally comprehensible by the client The artifacts of the requirements workflow must therefore be expressed in a natural (human) language All natural languages are imprecise

The Analysis Workflow (contd)
Example from a manufacturing information system: “A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant” To what does it refer? The part record? The plant record? Or the database?

Two separate workflows are needed The requirements artifacts must be expressed in the language of the client The analysis artifacts must be precise, and complete enough for the designers

The Specification Document (contd)
Specification document (“specifications”) Constitutes a contract It must not have imprecise phrases like “optimal,” or “98 percent complete” Having complete and correct specifications is essential for Testing, and Maintenance The specification document must not have Contradictions Omissions Incompleteness

Software Project Management Plan
Once the client has signed off the specifications, detailed planning and estimating begins We draw up the software project management plan, including Cost estimate Duration estimate Deliverables Milestones Budget This is the earliest possible time for the SPMP

The Design Workflow The aim of the design workflow is to refine the analysis workflow until the material is in a form that can be implemented by the programmers Many nonfunctional requirements need to be finalized at this time, including Choice of programming language Reuse issues Portability issues Retain design decisions For when a dead-end is reached, and To prevent the maintenance team reinventing the wheel

Classical Design Architectural design Detailed design
Decompose the product into modules Detailed design Design each module: Data structures Algorithms

Object-Oriented Design
Classes are extracted during the object-oriented analysis workflow, and Designed during the design workflow Accordingly Classical architectural design corresponds to part of the object-oriented analysis workflow Classical detailed design corresponds to part of the object-oriented design workflow

The Implementation Workflow
The aim of the implementation workflow is to implement the target software product in the selected implementation language A large software product is partitioned into subsystems The subsystems consist of components or code artifacts

The Test Workflow The test workflow is the responsibility of
Every developer and maintainer, and The quality assurance group Traceability of artifacts is an important requirement for successful testing

Requirements Artifacts
Every item in the analysis artifacts must be traceable to an item in the requirements artifacts Similarly for the design and implementation artifacts

Analysis Artifacts The analysis artifacts should be checked by means of a review Representatives of the client and analysis team must be present The SPMP must be similarly checked Pay special attention to the cost and duration estimates

Design Artifacts Design reviews are essential
A client representative is not usually present

Implementation Artifacts
Each component is tested as soon as it has been implemented Unit testing At the end of each iteration, the completed components are combined and tested Integration testing When the product appears to be complete, it is tested as a whole Product testing Once the completed product has been installed on the client’s computer, the client tests it Acceptance testing

Implementation Artifacts (contd)
COTS software is released for testing by prospective clients Alpha release Beta release There are advantages and disadvantages to being an alpha or beta release site

Postdelivery Maintenance
Postdelivery maintenance is an essential component of software development More money is spent on postdelivery maintenance than on all other activities combined Problems can be caused by Lack of documentation of all kinds Two types of testing are needed Testing the changes made during postdelivery maintenance Regression testing All previous test cases (and their expected outcomes) need to be retained

Retirement Software is can be unmaintainable because
A drastic change in design has occurred The product must be implemented on a totally new hardware/operating system Documentation is missing or inaccurate Hardware is to be changed—it may be cheaper to rewrite the software from scratch than to modify it These are instances of maintenance (rewriting of existing software) It occurs when the client organization no longer needs the functionality provided by the product

The Phases of the Unified Process
The increments are identified as phases Figure 3.1

The Phases of the Unified Process (contd)
The four increments are labeled Inception phase Elaboration phase Construction phase Transition phase The phases of the Unified Process are the increments

In theory, there could be any number of increments In practice, development seems to consist of four increments Every step performed in the Unified Process falls into One of the five core workflows and also One of the four phases Why does each step have to be considered twice?

Workflow Technical context of a step Phase Business context of a step

The Inception Phase The aim of the inception phase is to determine whether the proposed software product is economically viable 1. Gain an understanding of the domain 2. Build the business model 3. Delimit the scope of the proposed project Focus on the subset of the business model that is covered by the proposed software product 4. Begin to make the initial business case

Elaboration Phase The aim of the elaboration phase is to refine the initial requirements Refine the architecture Monitor the risks and refine their priorities Refine the business case Produce the project management plan The major activities of the elaboration phase are refinements or elaborations of the previous phase

The Tasks of the Elaboration Phase
The tasks of the elaboration phase correspond to: All but completing the requirements workflow Performing virtually the entire analysis workflow Starting the design of the architecture

The Elaboration Phase: Documentation
The deliverables of the elaboration phase include: The completed domain model The completed business model The completed requirements artifacts The completed analysis artifacts An updated version of the architecture An updated list of risks The project management plan (for the rest of the project) The completed business case

Construction Phase The aim of the construction phase is to produce the first operational-quality version of the software product This is sometimes called the beta release The emphasis in this phase is on Implementation, and Testing Unit testing of modules Integration testing of subsystems Product testing of the overall system

The Construction Phase: Documentation
The deliverables of the construction phase include: The initial user manual and other manuals, as appropriate All the artifacts (beta release versions) The completed architecture The updated risk list The project management plan (for the remainder of the project) If necessary, the updated business case

The Transition Phase The aim of the transition phase is to ensure that the client’s requirements have indeed been met Faults in the software product are corrected All the manuals are completed Attempts are made to discover any previously unidentified risks This phase is driven by feedback from the site(s) at which the beta release has been installed

The Transition Phase: Documentation
The deliverables of the transition phase include: All the artifacts (final versions) The completed manuals

Programming Team Organization
Example: Sheila and Harry code two modules, m1 and m2, say What can go wrong Both Sheila and Harry may code m1, and ignore m2 Sheila may code m1, Harry may code m2. When m1 calls m2 it passes 4 parameters; but m2 requires 5 parameters Or, the order of parameters in m1 and m2 may be different Or, the order may be same, but the data types may be slightly different

Programming Team Organization (contd)
This has nothing whatsoever to do with technical competency Team organization is a managerial issue

Communications Problems
Example There are three channels of communication between the three programmers working on a project. The deadline is rapidly approaching but the code is not nearly complete “Obvious” solution: Add a fourth programmer to the team Figure 4.1

Communications Problems (contd)
But other three have to explain in detail What has been accomplished What is still incomplete Brooks’s Law Adding additional programming personnel to a team when a product is late has the effect of making the product even later

Team Organization Teams are used throughout the software production process But especially during implementation Here, the discussion is presented within the context of programming teams Two extreme approaches to team organization Democratic teams (Weinberg, 1971) Chief programmer teams (Brooks, 1971; Baker, 1972)

Democratic Team Approach
Basic underlying concept — egoless programming Programmers can be highly attached to their code They even name their modules after themselves They see their modules as extension of themselves

Democratic Team Approach (contd)
If a programmer sees a module as an extension of his/her ego, he/she is not going to try to find all the errors in “his”/“her” code If there is an error, it is termed a bug  The fault could have been prevented if the code had been better guarded against the “bug” “Shoo-Bug” aerosol spray

Democratic Team Approach (contd)
Proposed Solution Egoless programming Restructure the social environment Restructure programmers’ values Encourage team members to find faults in code A fault must be considered a normal and accepted event The team as whole will develop an ethos, a group identity Modules will “belong” to the team as whole A group of up to 10 egoless programmers constitutes a democratic team

Difficulties with Democratic Team Approach
Management may have difficulty Democratic teams are difficult to introduce into an undemocratic environment

Strengths of Democratic Team Approach
Democratic teams are enormously productive They work best when the problem is difficult They function well in a research environment Problem: Democratic teams have to spring up spontaneously

Classical Chief Programmer Team
Figure 4.3 Six programmers, but now only 5 lines of communication

Classical Chief Programmer Team (contd)
The basic idea behind the concept Analogy: chief surgeon directing an operation, assisted by Other surgeons Anesthesiologists Nurses Other experts, such as cardiologists, nephrologists Two key aspects Specialization Hierarchy

Successful manager and highly skilled programmer Does the architectural design Allocates coding among the team members Writes the critical (or complex) sections of the code Handles all the interfacing issues Reviews the work of the other team members Is personally responsible for every line of code

Back-up programmer Necessary only because the chief programmer is human The back-up programmer must be in every way as competent as the chief programmer, and Must know as much about the project as the chief programmer Does black-box test case planning and other tasks that are independent of the design process

Programmers Do nothing but program All other aspects are handled by the programming secretary

Impracticality of Classical CPT
The chief programmer must be a highly skilled programmer and a successful manager There is a shortage of highly skilled programmers There is a shortage of successful managers The qualities needed to be a highly skilled programmer are unlikely to be found in a successful manager, and vice versa

Impracticality of Classical CPT (contd)
The back-up programmer must be as good as the chief programmer But he/she must take a back seat (and a lower salary) waiting for something to happen to the chief programmer Top programmers, top managers will not do that The programming secretary does nothing but paperwork all day Software professionals hate paperwork Classical CPT is impractical

Beyond CP and Democratic Teams
We need ways to organize teams that Make use of the strengths of democratic teams and chief programmer teams, and Can handle teams of 20 (or 120) programmers A strength of democratic teams A positive attitude to finding faults Use CPT in conjunction with code walkthroughs or inspections

Beyond CP and Democratic Teams (contd)
Potential pitfall The chief programmer is personally responsible for every line of code He/she must therefore be present at reviews The chief programmer is also the team manager He/she must therefore not be present at reviews!

Figure 4.4 Solution Reduce the managerial role of the chief programmer

It is easier to find a team leader than a chief programmer Each employee is responsible to exactly one manager—lines of responsibility are clearly delineated The team leader is responsible for only technical management

Budgetary and legal issues, and performance appraisal are not handled by the team leader The team leader participates in reviews — the team manager is not permitted to do so The team manager participates in regular team meetings to appraise the technical skills of the team members

Larger Projects The nontechnical side is similar
Figure 4.5 The nontechnical side is similar For even larger products, add additional layers

Figure 4.6 Decentralize the decision-making process, where appropriate Useful where the democratic team is good

Synchronize-and-Stabilize Teams
Used by Microsoft Products consist of 3 or 4 sequential builds Small parallel teams 3 to 8 developers 3 to 8 testers (work one-to-one with developers) The team is given the overall task specification They may design the task as they wish

Synchronize-and-Stabilize Teams (contd)
Why this does not degenerate into hacker-induced chaos? Daily synchronization step Individual components always work together Rules Programmers must adhere to the time for entering the code into the database for that day’s synchronization Analogy Letting children do what they like all day… … but with a 9 P.M. bedtime

Extreme Programming Teams
Feature of XP All code is written by two programmers sharing a computer “Pair programming”

Strengths of Pair Programming
Programmers should not test their own code One programmer draws up the test cases, the other tests the code If one programmer leaves, the other is sufficiently knowledgeable to continue working with another pair programmer An inexperienced programmer can learn from his or her more experienced team member

Strengths of Pair Programming
Test cases are drawn up by one member of the team, tested by the other Knowledge is not all lost if one programmer leaves An inexperienced programmer can learn from an experienced colleague Centralized computers promote egoless programming

Stepwise Refinement A basic principle underlying many software engineering techniques “Postpone decisions as to details as late as possible to be able to concentrate on the important issues” Miller’s law (1956) A human being can concentrate on 7 ± 2 items at a time

Appraisal of Stepwise Refinement
A basic principle used in Every workflow Every representation The power of stepwise refinement The software engineer can concentrate on the relevant aspects Warning Miller’s Law is a fundamental restriction on the mental powers of human beings

Cost–Benefit Analysis
Compare costs and future benefits Estimate costs Estimate benefits State all assumptions explicitly Example: Computerizing KCEC

Cost–Benefit Analysis (contd)
Tangible costs/benefits are easy to measure Make assumptions to estimate intangible costs/benefits Improving the assumptions will improve the estimates

Software Metrics To detect problems early, it is essential to measure
Examples: LOC per month Defects per 1000 lines of code

The Five Basic Metrics Size Cost Duration Effort Quality
In lines of code, or better Cost In dollars Duration In months Effort In person months Quality Number of faults detected

Software Versions During maintenance, at all times there are at least two versions of the product: The old version, and The new version There are two types of versions: revisions and variations

Revisions Revision A version to fix a fault in the artifact We cannot throw away an incorrect version The new version may be no better Some sites may not install the new version Perfective and adaptive maintenance also result in revisions

Variations A variation is a version for a different operating system–hardware Variations are designed to coexist in parallel Figure 5.11

Testing There are two basic types of testing “V & V”
Execution-based testing Non-execution-based testing “V & V” Verification Determine if the workflow was completed correctly Validation Determine if the product as a whole satisfies its requirements

Software Quality Not “excellence”
The extent to which software satisfies its specifications Every software professional is responsible for ensuring that his or her work is correct Quality must be built in from the beginning

Software Quality Assurance
The members of the SQA group must ensure that the developers are doing high-quality work At the end of each workflow When the product is complete In addition, quality assurance must be applied to The process itself Example: Standards

Managerial Independence
There must be managerial independence between The development group The SQA group Neither group should have power over the other More senior management must decide whether to Deliver the product on time but with faults, or Test further and deliver the product late The decision must take into account the interests of the client and the development organization

Non-Execution-Based Testing
Underlying principles We should not review our own work Group synergy

Walkthroughs A walkthrough team consists of from four to six members
It includes representatives of The team responsible for the current workflow The team responsible for the next workflow The SQA group The walkthrough is preceded by preparation Lists of items Items not understood Items that appear to be incorrect

Managing Walkthroughs
The walkthrough team is chaired by the SQA representative In a walkthrough we detect faults, not correct them A correction produced by a committee is likely to be of low quality The cost of a committee correction is too high Not all items flagged are actually incorrect A walkthrough should not last longer than 2 hours There is no time to correct faults as well

Managing Walkthroughs (contd)
A walkthrough must be document-driven, rather than participant-driven Verbalization leads to fault finding A walkthrough should never be used for performance appraisal

Inspections An inspection has five formal steps Overview
Preparation, aided by statistics of fault types Inspection Rework Follow-up

Inspections (contd) An inspection team has four members
Moderator A member of the team performing the current workflow A member of the team performing the next workflow A member of the SQA group Special roles are played by the Reader Recorder

Fault Statistics Faults are recorded by severity
Example: Major or minor Faults are recorded by fault type Examples of design faults: Not all specification items have been addressed Actual and formal arguments do not correspond

Fault Statistics (contd)
For a given workflow, we compare current fault rates with those of previous products We take action if there are a disproportionate number of faults in an artifact Redesigning from scratch is a good alternative We carry forward fault statistics to the next workflow We may not detect all faults of a particular type in the current inspection

Comparison of Inspections and Walkthroughs
Two-step, informal process Preparation Analysis Walkthrough Five-step, formal process Overview Rework Follow-up

Metrics for Inspections
Inspection rate (e.g., design pages inspected per hour) Fault density (e.g., faults per KLOC inspected) Fault detection rate (e.g., faults detected per hour) Fault detection efficiency (e.g., number of major, minor faults detected per hour)

Execution-based Testing: What Should Be Tested?
We need to test correctness and also Utility: The extent to which the product meets the user’s needs Examples: Ease of use Useful functions Cost effectiveness Reliability: A measure of the frequency and criticality of failure Mean time between failures Mean time to repair Time (and cost) to repair the results of a failure

Execution-based Testing: What Should Be Tested?
Robustness : Is a function of The range of operating conditions The possibility of unacceptable results with valid input The effect of invalid input Performance The extent to which space and time constraints are met Real-time software is characterized by hard real-time constraints If data are lost because the system is too slow There is no way to recover those data

Who Should Perform Execution-Based Testing?
Programming is constructive Testing is destructive A successful test finds a fault So, programmers should not test their own code artifacts

Who Should Perform Execution-Based Testing? (contd)
Solution: The programmer does informal testing The SQA group then does systematic testing The programmer debugs the module All test cases must be Planned beforehand, including the expected output, and Retained afterwards

When Testing Stops Only when the product has been irrevocably discarded

Reuse Concepts Reuse is the use of components of one product to facilitate the development of a different product with different functionality Opportunistic (accidental) reuse First, the product is built Then, parts are put into the part database for reuse Systematic (deliberate) reuse First, reusable parts are constructed Then, products are built using these parts

Why Reuse? To get products to the market faster
There is no need to design, implement, test, and document a reused component On average, only 15% of new code serves an original purpose In principle, 85% could be standardized and reused In practice, reuse rates of no more than 40% are achieved Why do so few organizations employ reuse?

Impediments to Reuse Not invented here (NIH) syndrome
Concerns about faults in potentially reusable routines Cost of reuse The cost of making an item reusable The cost of reusing the item The cost of defining and implementing a reuse process Legal issues (contract software only) Lack of source code for COTS components

Portability Product P: Need product P', functionally equivalent to P:
Compiled by compiler C1, then runs on machine M1 under operating system O1 Need product P', functionally equivalent to P: Compiled by compiler C2, then runs on machine M2 under operating system O2 P is portable if it is cheaper to convert P into P' than to write P' from scratch

Why Portability? (contd)
On the contrary, portability is essential Good software lasts 15 years or more Hardware is changed every 4 years Upwardly compatible hardware works But it may not be cost effective Portability can lead to increased profits Multiple copy software Documentation (especially manuals) must also be portable

Planning and Estimating
Before starting to build software, it is essential to plan the entire development effort in detail Planning continues during development and then postdelivery maintenance Initial planning is not enough Planning must proceed throughout the project The earliest possible time that detailed planning can take place is after the specifications are complete

Planning and the Software Process
Figure 9.1 The accuracy of estimation increases as the process proceeds

Estimating Duration and Cost
Accurate duration estimation is critical Accurate cost estimation is critical Internal, external costs There are too many variables for accurate estimate of cost or duration

Metrics for the Size of a Product
Lines of code (LOC, KDSI, KLOC) FFP Function Points COCOMO

Lines of Code (LOC) Alternate metric
Thousand delivered source instructions (KDSI) Source code is only a small part of the total software effort Different languages lead to different lengths of code LOC is not defined for nonprocedural languages (like LISP)

Lines of Code (contd) It is not clear how to count lines of code
Executable lines of code? Data definitions? Comments? JCL statements? Changed/deleted lines? Not everything written is delivered to the client A report, screen, or GUI generator can generate thousands of lines of code in minutes

Lines of Code (contd) LOC is accurately known only when the product finished Estimation based on LOC is therefore doubly dangerous To start the estimation process, LOC in the finished product must be estimated The LOC estimate is then used to estimate the cost of the product — an uncertain input to an uncertain cost estimator

Metrics for the Size of a Product (contd)
Metrics based on measurable quantities that can be determined early in the software life cycle FFP Function points

FFP Metric For cost estimation of medium-scale data processing products The three basic structural elements of data processing products Files Flows Processes

FFP Metric (contd) Given the number of files (Fi), flows (Fl), and processes (Pr) The size (S), cost (C) are given by S = Fi + Fl + Pr C = b  S The constant b (efficiency or productivity) varies from organization to organization

Techniques of Cost Estimation
Expert judgment by analogy Bottom-up approach Algorithmic cost estimation models

Expert Judgment by Analogy
Experts compare the target product to completed products Guesses can lead to hopelessly incorrect cost estimates Experts may recollect completed products inaccurately Human experts have biases However, the results of estimation by a broad group of experts may be accurate The Delphi technique is sometimes needed to achieve consensus

Bottom-up Approach Break the product into smaller components
The smaller components may be no easier to estimate However, there are process-level costs When using the object-oriented paradigm The independence of the classes assists here However, the interactions among the classes complicate the estimation process

Algorithmic Cost Estimation Models
A metric is used as an input to a model to compute cost, duration An algorithmic model is unbiased, and therefore superior to expert opinion However, estimates are only as good as the underlying assumptions Examples SLIM Model Price S Model COnstructive COst MOdel (COCOMO)

Tracking Duration and Cost Estimates
Whatever estimation method used, careful tracking is vital

Components of a Software Project Management Plan
The work to be done The resources with which to do it The money to pay for it

Resources Resources needed for software development: People Hardware
Support software

Work Categories Project function Activity
Work carried on throughout the project Examples: Project management Quality control Activity Work that relates to a specific phase A major unit of work, With precise beginning and ending dates, That consumes resources, and Results in work products like the budget, design, schedules, source code, or users’ manual

Work Categories (contd)
Task An activity comprises a set of tasks (the smallest unit of work subject to management accountability)

Completion of Work Products
Milestone: The date on which the work product is to be completed It must first pass reviews performed by Fellow team members Management The client Once the work product has been reviewed and agreed upon, it becomes a baseline

Planning Testing The SPMP must explicitly state what testing is to be done Traceability is essential All black box test cases must be drawn up as soon as possible after the specifications are complete

Training Requirements
“We don’t need to worry about training until the product is finished, and then we can train the user” Training is generally needed by the members of the development group, starting with training in software planning A new software development method necessitates training for every member of the group

Training Requirements (contd)
Introduction of hardware or software tools of any sort necessitates training Programmers may need training in the operating system and/or implementation language Documentation preparation training may be needed Computer operators require training

Requirements Phase: Determining What the Client Needs
Misconception We must determine what the client wants We must determine what the client needs It is hard for a systems analyst to visualize a software product and its functionality The problem is far worse for the client A skilled systems analyst is needed to elicit the appropriate information from the client The client is the only source of this information

Requirements Phase: Determining What the Client Needs
The solution: Obtain initial information from the client Use this initial information as input to the Unified Process Follow the steps of the Unified Process to determine the client’s real needs

Overview of the Requirements Workflow
First, gain an understanding of the application domain (or domain, for short) The specific environment in which the target product is to operate Second, build a business model Model the client’s business processes Third, use the business model to determine the client’s requirements Iterate the above steps

Definitions Discovering the client’s requirements
Requirements elicitation (or requirements capture) Methods include interviews and surveys Refining and extending the initial requirements Requirements analysis

Interviewing The requirements team meet with the client and users to extract all relevant information There are two types of questions Close-ended questions require a specific answer Open-ended questions are asked to encourage the person being interviewed to speak out There are two types of interviews In a structured interview, specific preplanned questions are asked, frequently close-ended In an unstructured interview, questions are posed in response to the answers received, frequently open-ended

Interviewing (contd) Interviewing is not easy
An interview that is too unstructured will not yield much relevant information The interviewer must be fully familiar with the application domain The interviewer must remain open-minded at all times After the interview, the interviewer must prepare a written report It is strongly advisable to give a copy of the report to the person who was interviewed

Other Techniques Interviewing is the primary technique
A questionnaire is useful when the opinions of hundreds of individuals need to be determined Examination of business forms shows how the client currently does business Direct observation of the employees while they perform their duties can be useful Videotape cameras are a modern version of this technique But, it can take a long time to analyze the tapes Employees may view the cameras as an unwarranted invasion of privacy

Initial Requirements The initial requirements are based on the initial business model Then they are refined The requirements are dynamic — there are frequent changes Maintain a list of likely requirements, together with use cases of requirements approved by the client

Initial Requirements (contd)
There are two categories of requirements A functional requirement specifies an action that the software product must be able to perform Often expressed in terms of inputs and outputs A nonfunctional requirement specifies properties of the software product itself, such as Platform constraints Reliability

Initial Requirements (contd)
Functional requirements are handled as part of the requirements and analysis workflows Some nonfunctional requirements have to wait until the design workflow The detailed information for some nonfunctional requirements is not available until the requirements and analysis workflows have been completed

Challenges of the Requirements Phase
Employees of the client organization often feel threatened by computerization The requirements team members must be able to negotiate The client’s needs may have to be scaled down Key employees of the client organization may not have the time for essential in-depth discussions Flexibility and objectivity are essential

The Specification Document Must Be
Informal enough for the client The client is generally not a computer specialist Formal enough for the developers It is the sole source of information for drawing up the design These two requirements are mutually contradictory The specification document is a contract between the client and the developers

Specification Document (contd)
Acceptance criteria It is vital to spell out a series of tests If the product passes the tests, it is deemed have satisfied its specifications

Informal Specifications (contd)
Conclusion Natural language is not a good way to specify a product

Entity-Relationship Modeling
Semi-formal technique Widely used for specifying databases Example Figure 11.10

Entity-Relationship Diagrams (contd)
Many-to-many relationship Figure 11.11

Comparison of Classical Analysis Techniques
Formal methods are Powerful, but Difficult to learn and use Informal methods have Little power, but are Easy to learn and use There is therefore a trade-off Ease of use versus power

Which Analysis Technique Should Be Used?
It depends on the Project Development team Management team Myriad other factors

Challenges of Classical Analysis
A specification document must be Informal enough for the client; but Formal enough for the development team Analysis (“what”) should not cross the boundary into design (“how”)

The Analysis Workflow The analysis workflow has two aims
Obtain a deeper understanding of the requirements Describe them in a way that will result in a maintainable design and implementation There are three types of classes: Entity classes Boundary classes Control classes

Entity class Models long-lived information Examples: Account Class Painting Class Boundary class Models the interaction between the product and the environment A boundary class is generally associated with input or output Purchases Report Class Sales Report Class

Control class Models complex computations and algorithms Examples: Compute Masterpiece Price Class Compute Masterwork Price Class Compute Other Painting Price Class

Challenges of the Object-Oriented Analysis Workflow
Do not cross the boundary into object-oriented design Do not allocate methods to classes yet Reallocating methods to classes during stepwise refinement is wasted effort

Data and Actions Two aspects of a product
Actions that operate on data Data on which actions operate The two basic ways of designing a product Operation-oriented design Data-oriented design Third way Hybrid methods For example, object-oriented design

Object-Oriented Design (OOD)
Aim Design the product in terms of the classes extracted during OOA OOD consists of two steps: Step 1. Complete the class diagram Determine the formats of the attributes Assign each method, either to a class or to a client that sends a message to an object of that class Step 2. Perform the detailed design

The Design Workflow Summary of the design workflow:
The analysis workflow artifacts are iterated and integrated until the programmers can utilize them Decisions to be made include: Implementation language Reuse Portability

The Design Workflow (contd)
The idea of decomposing a large workflow into independent smaller workflows (packages) is carried forward to the design workflow The objective is to break up the upcoming implementation workflow into manageable pieces Subsystems

Why the product is broken into subsystems: It is easier to implement a number of smaller subsystems than one large system If the subsystems are independent, they can be implemented by programming teams working in parallel The software product as a whole can then be delivered sooner

The architecture of a software product includes The various components How they fit together The allocation of components to subsystems The task of designing the architecture is specialized It is performed by a software architect

The architect needs to make trade-offs Every software product must satisfy its functional requirements (the use cases) It also must satisfy its nonfunctional requirements, including Portability, reliability, robustness, maintainability, and security It must do all these things within budget and time constraints The architect must assist the client by laying out the trade-offs

It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints Some sort of compromises have to be made The client has to Relax some of the requirements; Increase the budget; and/or Move the delivery deadline

The architecture of a software product is critical The requirements workflow can be fixed during the analysis workflow The analysis workflow can be fixed during the design workflow The design workflow can be fixed during the implementation workflow But there is no way to recover from a suboptimal architecture The architecture must immediately be redesigned

Challenges of the Design Phase
The design team should not do too much The detailed design should not become code The design team should not do too little It is essential for the design team to produce a complete detailed design

Challenges of the Design Phase (contd)
We need to “grow” great designers Potential great designers must be Identified, Provided with a formal education, Apprenticed to great designers, and Allowed to interact with other designers There must be specific career path for these designers, with appropriate rewards

Implementation Real-life products are generally too large to be implemented by a single programmer

Choice of Programming Language (contd)
The language is usually specified in the contract But what if the contract specifies that The product is to be implemented in the “most suitable” programming language What language should be chosen?

Example QQQ Corporation has been writing COBOL programs for over 25 years Over 200 software staff, all with COBOL expertise What is “the most suitable” programming language? Obviously COBOL

What happens when new language (C++, say) is introduced C++ professionals must be hired Existing COBOL professionals must be retrained Future products are written in C++ Existing COBOL products must be maintained There are two classes of programmers COBOL maintainers (despised) C++ developers (paid more) Expensive software, and the hardware to run it, are needed 100s of person-years of expertise with COBOL are wasted

The only possible conclusion COBOL is the “most suitable” programming language And yet, the “most suitable” language for the latest project may be C++ How to choose a programming language Cost–benefit analysis Compute costs and benefits of all relevant languages

Good Programming Practice
Use of consistent and meaningful variable names “Meaningful” to future maintenance programmers “Consistent” to aid future maintenance programmers

Use of Consistent and Meaningful Variable Names
A code artifact includes the variable names freqAverage, frequencyMaximum, minFr, frqncyTotl A maintenance programmer has to know if freq, frequency, fr, frqncy all refer to the same thing If so, use the identical word, preferably frequency, perhaps freq or frqncy,but not fr If not, use a different word (e.g., rate) for a different quantity

Consistent and Meaningful Variable Names
We can use frequencyAverage, frequencyMyaximum, frequencyMinimum, frequencyTotal We can also use averageFrequency, maximumFrequency, minimumFrequency, totalFrequency But all four names must come from the same set

The Issue of Self-Documenting Code
Self-documenting code is exceedingly rare The key issue: Can the code artifact be understood easily and unambiguously by The SQA team Maintenance programmers All others who have to read the code

Self-Documenting Code Example
Code artifact contains the variable xCoordinateOfPositionOfRobotArm This is abbreviated to xCoord This is fine, because the entire module deals with the movement of the robot arm But does the maintenance programmer know this?

Prologue Comments Minimal prologue comments for a code artifact
Figure 14.1

Code Reuse Code reuse is the most common form of reuse
However, artifacts from all workflows can be reused

Integration The approach up to now: This is a poor approach Better:
Implementation followed by integration This is a poor approach Better: Combine implementation and integration methodically

Top-down Integration If code artifact mAbove sends a message to artifact mBelow, then mAbove is implemented and integrated before mBelow One possible top-down ordering is a,b,c,d,e,f,g, h,i,j,k,l,m Figure 14.6 (again)

Top-down Integration (contd)
Advantage 1: Fault isolation A previously successful test case fails when mNew is added to what has been tested so far The fault must lie in mNew or the interface(s) between mNew and the rest of the product Advantage 2: Stubs are not wasted Each stub is expanded into the corresponding complete artifact at the appropriate step Advantage 3: Major design flaws show up early

Bottom-up Integration
If code artifact mAbove calls code artifact mBelow, then mBelow is implemented and integrated before mAbove One possible bottom-up ordering is l,m,h,i,j,k,e, f,g,b,c,d,a Figure 14.6 (again)

Bottom-up Integration (contd)
Advantage 1 Operational artifacts are thoroughly tested Advantage 2 Operational artifacts are tested with drivers, not by fault shielding, defensively programmed artifacts Advantage 3 Fault isolation

Sandwich Integration Logic artifacts are integrated top-down
Operational artifacts are integrated bottom-up Finally, the interfaces between the two groups are tested Figure 14.7

Sandwich Integration (contd)
Advantage 1 Major design faults are caught early Advantage 2 Operational artifacts are thoroughly tested They may be reused with confidence Advantage 3 There is fault isolation at all times

The Implementation Workflow
The aim of the implementation workflow is to implement the target software product A large product is partitioned into subsystems Implemented in parallel by coding teams Subsystems consist of components or code artifacts

The Implementation Workflow (contd)
Once the programmer has implemented an artifact, he or she unit tests it Then the module is passed on to the SQA group for further testing This testing is part of the test workflow

Unit-testing Techniques
Neither exhaustive testing to specifications nor exhaustive testing to code is feasible The art of testing: Select a small, manageable set of test cases to Maximize the chances of detecting a fault, while Minimizing the chances of wasting a test case Every test case must detect a previously undetected fault

Black-Box and Glass-Box Unit-testing Techniques
We need a method that will highlight as many faults as possible First black-box test cases (testing to specifications) Then glass-box methods (testing to code)

Challenges of the Implementation Workflow
Management issues are paramount here Appropriate CASE tools Test case planning Communicating changes to all personnel Deciding when to stop testing

Postdelivery Maintenance
Any change to any component of the product (including documentation) after it has passed the acceptance test This is a short chapter But the whole book is essentially on postdelivery maintenance In this chapter we explain how to ensure that maintainability is not compromised during postdelivery maintenance

Why Postdelivery Maintenance Is Necessary
Corrective maintenance To correct residual faults Analysis, design, implementation, documentation, or any other type of faults

Why Postdelivery Maint. Is Necessary (contd)
Perfective maintenance Client requests changes to improve product effectiveness Add additional functionality Make product run faster Improve maintainability

Why Postdelivery Maint. Is Necessary (contd)
Adaptive maintenance Responses to changes in the environment in which the product operates The product is ported to a new compiler, operating system, and/or hardware A change to the tax code 9-digit ZIP codes

What Is Required of Postdelivery Maintenance Programmers?
At least 67 percent of the total cost of a product accrues during postdelivery maintenance Maintenance is a major income source Nevertheless, even today many organizations assign maintenance to Unsupervised beginners, and Less competent programmers

What is Required of Postd. Maint. Prog. (contd)?
Postdelivery maintenance is one of the most difficult aspects of software production because Postdelivery maintenance incorporates aspects of all other workflows

Corrective Maintenance
What tools does the maintenance programmer have to find the fault? The defect report filed by user The source code And often nothing else

Corrective Maintenance (contd)?
A maintenance programmer must therefore have superb debugging skills The fault could lie anywhere within the product The original cause of the fault might lie in the by now non-existent specifications or design documents Suppose that the maintenance programmer has located the fault Problem: How to fix it without introducing a regression fault

Corrective Maintenance (contd)
How to minimize regression faults Consult the detailed documentation for the product as a whole Consult the detailed documentation for each individual module What usually happens There is no documentation at all, or The documentation is incomplete, or The documentation is faulty

The programmer must deduce from the source code itself all the information needed to avoid introducing a regression fault The programmer now changes the source code

The Programmer Now Must
Test that the modification works correctly Using specially constructed test cases Check for regression faults Using stored test data Add the specially constructed test cases to the stored test data for future regression testing Document all changes

Major skills are required for corrective maintenance Superb diagnostic skills Superb testing skills Superb documentation skills

Adaptive and Perfective Maintenance
The maintenance programmer must go through the Requirements Specifications Design Implementation and integration workflows, using the existing product as a starting point

Adaptive and Perfective Maintenance (contd)
When programs are developed Specifications are produced by analysis experts Designs are produced by design experts Code is produced by programming experts But a maintenance programmer must be expert in all three areas, and also in Testing, and Documentation

Conclusion No form of maintenance
Is a task for an unsupervised beginner, or Should be done by a less skilled computer professional

The Rewards of Maintenance
Maintenance is a thankless task in every way Maintainers deal with dissatisfied users If the user were happy, the product would not need maintenance The user’s problems are often caused by the individuals who developed the product, not the maintainer The code itself may be badly written Postdelivery maintenance is despised by many software developers Unless good maintenance service is provided, the client will take future development business elsewhere Post delivery maintenance is the most challenging aspect of software production — and most thankless

The Rewards of Maintenance (contd)
How can this situation be changed? Managers must assign maintenance to their best programmers, and Pay them accordingly

Reverse Engineering When the only documentation for postdelivery maintenance is the code itself Start with the code Recreate the design Recreate the specifications (extremely hard) CASE tools can help (flowcharters, other visual aids)

Reverse Engineering (contd)
Reengineering Reverse engineering, followed by forward engineering Lower to higher to lower levels of abstraction Restructuring Improving the product without changing its functionality Examples: Structuring code Improving maintainability

Reverse Engineering (contd)
What if we have only the executable code? Treat the product as a black box Deduce the specifications from the behavior of the current product

Challenges of Postdelivery Maintenance
The hardest challenge to solve Maintenance is harder than development, but Developers tend to look down maintainers, and Are frequently paid more

Overview SOFTWARE ENGINEERING Overview.

Similar presentations

Presentation on theme: "Overview SOFTWARE ENGINEERING Overview."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Overview SOFTWARE ENGINEERING Overview.

Similar presentations

Presentation on theme: "Overview SOFTWARE ENGINEERING Overview."— Presentation transcript:

Similar presentations

About project

Feedback