CS 3240 Final

Techniques for evaluation

User observation: - Observe a participant interacting with system etc. Inspection (heuristic inspection), Walkthrough: - Various techniques - No participants usually involved Questionnaires, Surveys Observation of real users in their real world: - For understanding users, needs, and requirements

Push down field

When a field is only used by some subclasses Slide 27

Remove setting method

When a field should be set at creation time and never altered Slide 29

Inline method

When a method's body is as clear as its name void getRating() { return (moreThanFiveDeliveries()) ? 2 : 1; } boolean moreThanFiveDeliveries() { return _moreThanFiveDeliveries > 5; } Becomes... void getRating() { return (_moreThanFiveDeliveries > 5) ? 2 : 1; }

Remove parameter

When a parameter is no longer used by the method body Slide 28

Extract interface

When several clients use the same subset of a class's interface, or two classes have part of their interfaces in common Pic on slide 22 of refactoring slides

Rename method

When the name of a method does not reveal its purpose Slide 30

Encapsulate field

When there is a public field public String _name; Becomes... private String _name; public String getName() { return _name; } public void setName (String arg) { _name = arg; }

Pull up field

When two subclasses have the same field Pic on slide 26

Extract method

When you have a code fragment that can be grouped together void printOwing(double amount) { printBanner(); System.out.println ("name/amt: " + name + amount); } Becomes... void printOwing(double amount) { printBanner(); printDetails(amount); } void printDetails (double amount) { System.out.println ("name/amt: " + name + amount); }

Introduce parameter object

When you have a group of parameters that go naturally together Pic on slide 25 of refactoring slides

Assembling a team

- May not be possible to appoint the ideal people to work on a project - Project budget may not allow for the use of highly-paid staff; - Staff with the appropriate experience may not be available; - An organization may wish to develop employee skills on a software project. - Managers have to work within these constraints especially when there are shortages of trained staff.

Threat Modeling

- A form of security risk assessment for software Details in OWASP Testing Guide Introduction and other docs: - Identify and evaluate "assets" in your system - What are potential vulnerabilities? - Threats: what "vectors", scenarios, etc. could an attacker use against your system? - Mitigation strategies to protect against realistic threats

Selecting group members

- A manager or team leader's job is to create a cohesive group and organize their group so that they can work together effectively. - This involves creating a group with the right balance of technical skills and personalities, and organizing that group so that the members work together effectively.

BSD License

- A set of permissive licenses - Two variants are GPL-compatible - Meaning they can be combined with GPL code, although the resulting code must be released under the GPL - Thus, they are considered both "free software licenses" by the FSF as well as "open source licenses" by the OSI - The 4-clause variant is not, due to the advertising clause:All advertising materials mentioning features or use of this software must display the following acknowledgement... - This clause (and variant) has since fallen out of favor - Django is released under the BSD license

Motivating People

- An important role of a manager is to motivate the people working on a project. - Motivation means organizing the work and the working environment to encourage people to work effectively. - If people are not motivated, they will not be interested in the work they are doing. They will work slowly, be more likely to make mistakes and will not contribute to the broader goals of the team or the organization. - Motivation is a complex issue but it appears that their are different types of motivation based on: Basic needs (e.g. food, sleep, etc.); Personal needs (e.g. respect, self-esteem); Social needs (e.g. to be accepted as part of a group).

Integrity

- Can we assure that data is accurate and consistent over its lifetime? Issues in project: Can information be modified, corrupted? - How to insure integrity: Hashing Think back: what's a hash function for? How used here? Algorithms: MD5, SHA-1, others

Source Code Review

- Complements penetration testing Examples of security issues that might be uncovered: - Access control problems - Cryptography weaknesses - Backdoors

Principles of Good Layout

- Create natural groupings - Separate currently active components - Emphasize important components - Use "white space" effectively (or: separate components when appropriate) - Make controls visible - Balance aesthetics and usability

Confidentiality

- Data at rest, data in transit - Encryption - Authentication - Authorization - Your implementation of your project? - Vulnerabilities - Risk modeling, threat assessment

Lesser GPL (LGPL)

- Designed as a compromise between the restrictive GPL and the permissive MIT/BSD licenses Differences between LGPL and GPL: - LGPL does not place restrictions on software that links with LPGL code - Thus, primarily used for software libraries - Originally called "Library GPL" - Need not display license from the command line - Software using this license: OpenOffice.org, LibreOffice

Group communications

- Good communications are essential for effective group working. - Information must be exchanged on the status of work, design decisions and changes to previous decisions. - Good communications also strengthens group cohesion as it promotes understanding. Group size: - The larger the group, the harder it is for people to communicate with other group members. Group structure: - Communication is better in informally structured groups than in hierarchically structured groups. Group composition: - Communication is better when there are different personality types in a group and when groups are mixed rather than single sex. The physical work environment: - Good workplace organization can help encourage communications.

Group compostion

- Group composed of members who share the same motivation can be problematic - Task-oriented - everyone wants to do their own thing; - Self-oriented - everyone wants to be the boss; - Interaction-oriented - too much chatting, not enough work. - An effective group has a balance of all types. - This can be difficult to achieve software engineers are often task-oriented. - Interaction-oriented people are very important as they can detect and defuse tensions that arise.

HCI

- Human computer interface - Where people "meet" or come together with machines or computer-based systems - Physical interface (e.g. buttons, screens, menus, etc.) - Logical interface - The model a system presents a user - Set of tasks available and how they're organized

Reverse engineering

- If piece of hardware is lawfully obtained, then reverse engineering is lawful - EULAs generally forbid for software - DMCA (Digital Millennium Copyright Act) allow for reverse engineering of software if: 1. You legally obtained it 2. It is specifically to achieve interoperability between computer programs

Testing Techniques

- Inspections and reviews - Threat modeling - Penetration testing

Teamwork

- Most software engineering is a group activity - The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. - A good group is cohesive and has a team spirit. The people involved are motivated by the success of the group as well as by their own personal goals. - Group interaction is a key determinant of group performance. - Flexibility in group composition is limited Managers must do the best they can with available people.

Managing people

- People are an organization's most important assets. - The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. - Poor people management is an important contributor to project failure.

Refactoring

- Significant work that improves code - Doesn't move towards completing other requirements - "technical debt" - slows down degradation through change - modifies program to improve structure, reduce its complexity, make it easier to understand - does not add functionality

MIT license

- Simplest non-restrictive open source license - Three parts: 1. Anybody can use the software for free for any use 2. The license must be included in the software 3. There is no warranty - Both Ruby on Rails and CakePHP are released under this license

Group organization (cont.)

- Small software engineering groups are usually organized informally without a rigid structure. - For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects. - Agile development is always based around an informal group on the principle that formal structure inhibits information exchange

Code smells

- Smells often lead to refactoring - Popularized by Martin Fowler def: a common issue in code quality, often small issue - easy for experienced programmer to recognize - Like design patterns, good practice "codified" and documented by practitioners

Group organization

- The way that a group is organized affects the decisions that are made by that group, the ways that information is exchanged and the interactions between the development group and external project stakeholders. Key questions include: - Should the project manager be the technical leader of the group? - Who will be involved in making critical technical decisions, and how will these be made? - How will interactions with external stakeholders and senior company management be handled? - How can groups integrate people who are not co-located? - How can knowledge be shared across the group?

Need satisfaction

- Typically, in software development groups, basic physiological and safety needs are not an issue. Social: - Provide communal facilities; - Allow informal communications e.g. via social networking Esteem: - Recognition of achievements; - Appropriate rewards. Self-realization: - Training - people want to learn more; - Responsibility.

Inspections and Reviews

- You know about source code reviews, but... - Security experts can also review people, policies, and processes Examples: - Review if a development team understands and is carrying out secure coding practices - Review if requirements or design documents and decisions address security concerns - Review if a devops team is managing a deployed system

Copyright

- comes from Article I, Section 8, clause 8 of US constitution - Software publisher grants use of one or more copies of software - Ownership remains with software company - in order to use it, have to agree to terms in End User License Agreement (EULA)

GPL (General Public License)

- very restrictive, prevented some companies from releasing their code under it - called "copyleft" - All derivative works must be released under the SAME license - even if it is only a small part that uses the GPL - This causes it to be very restrictive - This is called a "viral" license - GNU software: Linux kernel, gcc/g++, etc.

Principles of Security

CIA: Confidentiality, Integrity, Availability Confidentiality: - Making sure data only viewable by authorized users Integrity: - Ensuring accuracy and consistency of data over its entire life-cycle Availability: - Data and services are available when needed, avoiding single points of failure, etc.

Availability

Can we insure data and services are available when needed? Avoid single point of failure If something breaks, can we recover data etc? Often related to issues of: Deployment, architecture Fault tolerant systems. Redundant systems. Even HW decisions like RAID. Multiple servers Know the term "DevOps"?

People management factors

Consistency: - Team members should all be treated in a comparable way without favorites or discrimination. Respect: - Different team members have different skills and these differences should be respected. Inclusion: - Involve all team members and make sure that people's views are considered. Honesty: - You should always be honest about what is going well and what is going badly in a project.

Principles explained

Create natural groupings: - Both commands/controls and information displayed - Is there a natural structure? - Use color, fonts, separators etc. Separate Currently Active Components: - Help user focus on what they're doing now. - Can pick back up if interrupted - Make things prominent by color, placement,... Emphasize important components: - Use color, type, animations, etc. - Be selective Use "white space" effectively (or: separate components when appropriate): - White-space in GUIs, physical space on physical devices - Alternative to lines, colors - Supports grouping for perception - In physical devices, supports physical usability Make controls visible: - Support recognition over recall - Control must be obvious, but also the controls function - Consider conventions, consistency, ... Balance aesthetics and usability: - Some say: "Looking pretty is half the battle" - How important? What trade-offs?

Bad smells in coding (cont.)

Data clumping: - occurs when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. - These can often be replaced with an object that encapsulates all of the data. Speculative generality: - This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed Primitive obsession: - giving up on the specialized purpose of a class and using primitive data types rather than class objects

Bad smells in coding

Duplicate code: - Same or very similar code is included in different places in a program - Can be removed and implemented as a single method Long methods: - If method is too long, it can be redesigned as a series of shorter methods Switch (case) statements: - Often involve duplication, where switch depends on type of value - May be scattered around the program - in OO languages, can use polymorphism to achieve same thing

Process of Refactoring

Form of software maintenance: - not done in separate state - not adaptive, not an enhancement - Goal is to reduce risk of change later Steps: - Review code to identify issues - Rule 1: Don't add or change functionality - Rule 2: One thing at a time - Rule 3: Retest

UC Berkeley Security Testing

Goal: - Test if app meets security requirements - Done annually for apps that handle certain kinds of data Process: - First, train/explain process to app owner - Second, understand potential threats Meeting with security personnel (both technical and policy) and application stakeholders. Those who understand app's "use-cases" (how it's used). Meeting goal: determine what to test based on security risk analysis. Must understand architecture, design, data flow and storage. Emphasis on "life-cycle" of secure data. - Third, testing done by a separate security team Finally, report, debriefing, fixes, re-testing, etc.

Who owns UVA students' software?

If you were paid by the university... ... as a graduate student, paid RA, etc... ... then the university would own your code But if you are not paid by the university, you own your code And can release it, GPL it, sell it, etc. For a group project, the system is considered to be jointly-owned, and it's up to the group to hash out any details... This is a university policy, and it follows federal copyright law Django is released under the BSD license Ruby on Rails and CakePHP are both released under the MIT license But if you include any GPL code, you MUST release the entire system under the GPL You can link to LGPL libraries just fine... If you are developing real software for real customers, you have to pay attention to this! If you release it under the GPL, you can never "un-do" that decision!

Group Cohesiveness

In a cohesive group, members consider the group to be more important than any individual in it. The advantages of a cohesive group are: - Group quality standards can be developed by the group members. - Team members learn from each other and get to know each other's work; Inhibitions caused by ignorance are reduced. - Knowledge is shared. Continuity can be maintained if a group member leaves. - Refactoring and continual improvement is encouraged. Group members work collectively to deliver high quality results and fix problems, irrespective of the individuals who originally created the design or program.

HCI & Evaluation

Iterative design & evaluation is a continuous process that examines: - Early ideas for conceptual model - Early prototypes of the new system - Later, more complete prototypes - Existing systems - Designers need to check that they understand users' requirements. - Evaluation may teach you about your users as well as about your current design

Range of concerns

Make an interactive system be useful for a task, and support that task effectively: - Easy to use, easy to learn, avoid errors - Must understand users, understand users' tasks Create a usable logical interface: - A user's conceptual model of the system - Overall design of how we interact Physical and low-level design: - Physical interface: buttons, keys, screens - SW interface: menus, screens, colors Evaluating usability: - During development, after completion

OWASP Summary

Multiple ways to approach security testing: - Occur at different phases in the lifecycle - Different strengths and weaknesses - Balanced approach desirable Important! Should be part of an organization's standard software process methodology - Defined, repeatable, verifiable

Red/Green/Refactor

Red - write a test that doesn't work or compile Green - wrote code to make the test work quickly (not the best code) Refactor - Eliminate duplication and other problems you did to just make the test work

OWASP Testing

Requirements analysis: - Security requirements defined - Abuse cases, misuse cases Requirements specification: - Data modeling: - Not just what it is, but what security it must have Obviously much has to be done in design and implementation, but this is driven by requirements (whenever defined)

Goal & Design principles

Some well-known usability goals: - Effective to use (an overall measure, perhaps) - Efficient to use - Safe to use (prevent errors, recover from errors) - Have good utility (help users accomplish tasks) - Easy to learn - Easy to remember how to use

Penetration Testing

Testing a running system from outside (as a blackbox, as if you were a user) with the goal of finding and exploiting vulnerabilities: - Popular, particularly for network and OS security - But often vulnerabilities are known in advance.(Does this particular system deployment have these?) For web applications: - There are some known general types of threats (e.g. XSS) - But since most apps are custom-made, doing penetration testing is more challenging Limitations: late in the SDLC, negative result not sufficient

People Capability Maturity Model (P-CMM)

The P-CMM is a framework for assessing how well organizations manage the development of their staff. It highlights best practice in people management and provides a basis for organizations to improve their people management processed. It is best suited to large rather than small, informal companies. - helps organizations characterize the maturity of their workforce practices, - establish a program of continuous workforce development, - set priorities for improvement actions, - integrate workforce development with process improvement, and - establish a culture of excellence.

Team effectiveness

The people in the group: - You need a mix of people in a project group as software development involves diverse activities such as negotiating with clients, programming, testing and documentation. The group organization: - A group should be organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected. Technical and managerial communications: - Good communications between group members, and between the software engineering team and other project stakeholders, is essential.

Human needs hiearchy

pic on slide 6 of Managing People