Pears of Wisdom - Software Engineering Books Notes

Página 1

Notes from ...

CHAPTER 1: Software Engineering Overview

NO project can succeed without a plan

Step 1: Figure out requirements

Depends on who the customer is.

Determine customers wants and needs.

Turn wants and needs in requirements doc.

Use requirements doc to manage change.

Step 2: High-Level Design

Includes steps like platform, data design, interfaces, etc.

High level design should cover all aspects of Requirements Doc

Step 3: Low-Level Design

How the pieces of the high-level design should work

Who should do each piece

May lead to changes in requirements and high-level design

Step 4: Development

Refine low-level design until it can be implemented

Remember to write tests and implement in-dev testing

Step 5: Post Dev-Iterative Testing

Use integration tests, black-box, white-box, etc. testing after development cycles.

If you find bugs, make changes and RETEST

THE LONGER A BUG REMAINS UNDETECTED, THE HARDER IT IS TO FIX.

Testing is critical at every stage.

Step 6: Deployment

Depends heavily on what you've built.

May require new hardware, networks, training, support, maintenance, etc.

Step 7: Maintenance

When people start using something, they'll find bugs.

The more successful an application the more bugs people will find.

Need a plan to address these quickly.

Step 8: Wrap-up

Do a post-mortem, decide what went right, what went wrong, etc.

Determine how to improve things for the next cycle, etc.

Do this immediately before people forget what happened.

As you work on all these steps, try to find ways to keep everyone actively engaged.

Consider taking an iterative type approach. Have people start step 2 as soon as some part of step 1 is complete, etc.

It is especially good to have testers think about the issue as soon as possible as it might result in changes to low-level, high-level, and even requirements.

================================================================================

CHAPTER 2: Before Beginning

There are certain things that ALL software projects require regardless of content.

Even a simple software project may have tons of documentation. So you need document management.

This doc management system needs version and change control.

It may be wise to implement a change control board to keep changes from happening too rapidly.

A doc management system should have:

People can share documents so that they can all view and edit them.

Only one person can edit a document at a given time.

You can fetch the most recent version of a document.

You can fetch a specific version of a document by specifying either a date or version number. You can search documents for tags, keywords, and anything else in the documents.

You can compare two versions of a document to see what changed, who changed it, and when the change occurred. (Ideally, you should also see notes indicating why a change was made; although, that’s a less common feature.)

The ability to access documents over the Internet or on mobile devices.

The ability for multiple people to collaborate on documents (so they can see each other making changes to a shared document).

Integration into other tools such as Microsoft Office or project management software.

Document branches so that you can split a document into two paths for future changes. (This is more useful with program code where you might need to create two parallel versions of the program. Even then it can lead to a lot of confusion.)

User roles and restricted access lists. E‐mail change notification.

Workflow support and document routing

Collect ALL relevant documentation in the documentation management system. It will help mitigate disputes, etc.

Do something to reduce the signal to noise ratio in e-mail like prefixing them with something: [PROJECT BLAH]

Consider pulling out the e-mails into a searchable text file, add them to doc management.

You can further refine e-mails with things like [admin] [hl-design] [testing] etc.

You need source control.

Source control is different from document control.

Source code is written for people.

Make sure to comment and document your code thoroughly.

Code documentation should include high and low level design info, and overview of methods and explanations of tricky logic.

Good code should be self-documenting is bullshit.

Finally, don't forget the actual application documentation.

The better that documentation, the easier the whole roll out will be.

================================================================================

CHAPTER 3: Project Management

Aside from being able to trace changes, developments, etc., someone needs to monitor work in real-time.

Someone needs to track what is happening, what should be happening, and why they might not match.

Project managers make sure goals are set and tracked and keep people focused.

Executive support is critical for project success.

An Executive Champion duties include:

Providing necessary resources such as budgets, hardware, and personnel Making “go/no-go” decisions and deciding when to cancel the project

Giving guidance on high‐level issues such as how the project fits into the company’s overall business strategy

Helping navigate any administrative hurdles required by the company

Defining the business case

Working with users and other stakeholders to get buy‐in

Providing feedback to developers about implemented features

Buffering the project from external distractions (such as the rest of the company) Refereeing between managers, users, developers, and others interested in the project Supporting the project team

Staying out of the way

A Project Manager is the highest ranking member of a project team.

A Project Manager's duties include:

Helping define the project requirements

Tracking project tasks

Responding to unexpected problems

Managing risk

Keeping users (and the executive champion) up‐to‐date on the project’s progress

Providing an interface between customers and developers

Managing resources such as time, people, budget, hardware, and software tools

Managing delivery

PERT Charts (Program Evaluation and Review Technique)

A graph that uses nodes (circles or boxes) and links (arrows) to show the precedence relationships among the tasks in a project.

They come in two flavors: activity on arrow (AOA), where arrows represent tasks and nodes represent milestones and activity on node (AON), where nodes represent tasks and arrows represent precedence relations.

Making a PERT chart is slightly complicated, Refer back to page 34 for steps.

Critical Path is a longest path (there may be several with the same length) through the system

If anything is delayed in the critical path, the whole project will be delayed.

PERT Charts can be used to find critical paths.

PERT Charts can also show you 'nearly critical paths', those items that are a small fraction from a critical path.

This will help you determine what MUST happen and what can be practically delayed.

It is also good for reasoning about the project generally.

Gantt Charts

Similar to PERT, it shows the order of tasks, but displays the time factor horizontally on a calendar.

Gantt charts make it easier to see critical path, etc.

These methods are only valuable if you can estimate the work correctly.

If all your estimates are wrong you've got Garbage In, Garbage Out (GIGO).

You can improve estimation by:

Getting Experience, either yourself or asking people who have done it before.

Break complicated tasks into simpler tasks.

Designing a new database is hard, writing to a file, grouping files together, and indexing files is easier.

Look for similarities, see if this is similar to another task that takes a certain amount of time.

Be prepared for the unexpected:

People get sick, assumptions are wrong, IT systems go down. Know that will happen and pad in some time.

Track your progress carefully

People are often more sanguine about a project when they have just started.

Track what is actually happening and see if it lines up with your estimates.

Demanding time-lines not slip will likely cause people to burn-out or the project to fail.

Don't fall into the trap of assuming throwing more people at the problem will ix it.

Use a Risk Management approach when estimating.

Be aware that there is more risk with newer projects and less experienced people.

================================================================================

CHAPTER 4: Requirements Gathering

Requirements gathering is important, just remember that a project can fail at almost any point.

Requirements are the features that your application must provide. This can be anything from a single page to hundreds.

Good Requirements are:

Clear, concise, and easy to understand. Avoid parlance and jargon. Make sure to define technical terms where applicable

Unambiguous. Use non-subjective terms, like shortest route instead of best route.

Consistent. Especially with each-other.

Prioritized.

MOSCOW Method: Requirements should be prioritized by,

MUST = Required

SHOULD = Important

COULD = Desirable

WON'T = Not in this release

Verifiable. Make sure that the requirements can be precisely defined.

Avoid:

Comparative - faster, better, more

Imprecise Adjectives - fast, user-friendly, efficient

Vague commands - minimize, improve, optimize

Requirement Categories: Requirements are directed at different audiences and focus on different aspects of the software.

This list is not exhaustive but it suggests the sort of requirements you might consider gathering.

Business Requirements: Layout high-level goals. Explain what a customer will achieve with the software.

User Requirements: Describe how the project will be used by end-users.

Note that it is possible to be too specific and limit better options at design time.

Functional Requirements: Detailed statements about a projects capabilities.

Similar to user requirements but include things a user may not see, like back-ups, throughput, etc.

Nonfunctional Requirements: Statements about the quality of the application's functionality.

This would include things like supporting 20 concurrent users.

Implementation Requirements: Statements about transition to a new system, staffing requirements, hardware needs, etc.

FURPS

Functionality: Describes the systems general features

Usability: What the program should look-like and other user-oriented requirements

Reliability: Obvious

Performance: How efficient should the system be

Supportability: How easy should it be to test, maintain, etc.

FURPS+ = FURPS + the following

Design Constraints: Considerations due to hardware, software, and other factors

Implementation Requirements: Considerations due to things like ISO, security, etc.

Interface Requirements: Considerations on system interfaces due to data exchange, interchange, etc.

Physical Requirements: Considerations due to physical devices such as power consumption, portability, touch screens.

Good Review pages 65 - 66 (97 - 98)

Common Requirements:

Screens, Menus, Navigation, Work flow, Login, User types, Auditing, Archiving, Configuration

Use Who, What, When, Where, Why, and How

Study Users, they will tell you what they do, what they hate, love, etc.

Turn what you've learned by asking questions into requirements.

Copy existing systems that work, if possible, as far they work for your goals

Use people with experience (fast brain decisions)

Brainstorm, gather as many ideas as possible, don't exclude things, just focus on new and more ideas, cull later.

Focus on Quantity

Withhold Criticism

Encourage Unusual Ideas

Combine and Improve Ideas

Capture Requirements

UML

User Stories

Use Cases - A description of a series of interactions between actors.

Prototypes - A mockup of the application or sub-system

Requirement Specifications:

Villanova University has an example template in Word format at tinyurl.com/obqhatt

The North Carolina Enterprise Project Management Office has another one at tinyurl.com/n7ttqfh

Once requirements are gathered:

Validate: Are we doing the right things?

Verify: Are we doing the things right?

Remember, validation comes before verification.

It is okay to change requirements over time if they are controlled.

================================================================================

CHAPTER 5: High-Level Design

High-Level design is an abstract view of the system that shows how major pieces will fit together

It should include assumptions about the environment like the hardware and software used to develop and run the application.

Think of software development as the process of dissecting systems into pieces small enough to implement

High-level design is the first activity in this step

The goal is to divide the system into self contained atomic chunks that any team could implement

What to Specify in HLD:

Security:

OS Security, login, password expiration and standards,

Application Security, Use existing, add your own, LDAP vs. Kerberos, etc.

Data Security, In transit, at rest

Physical Security, safe on a laptop or does it need to be in a locked room?

Hardware:

Form Factor, OS, Printers, Network Components, Servers, Specialized Instruments, Audio/Video

User Interface

Usually a simple sketch works, indicate main methods and how they're accessed.

For things like tablets and phones, consider the navigational model

Describe special features like a clickable map, important tables, etc.

Try to give users an experience they expect, leverage existing designs if it helps.

Internal Interfaces

We should be able to define how the separated pieces interact with one another.

Make sure to get this part correct as it will allow better parallel work.

External Interfaces

This may not be 100% necessary but it is very common.

Carefully layout how the system will leverage other systems, what it expects what it provides, etc.

Architecture

This describes how all the pieces fit together.

There are several "standard" architectures to consider:

Monolithic:

A single program does everything from interacting with the DB to displaying UI, to creating invoices.

Tightly coupled, so lacks flexibility

Requires deep understanding of the system

Generally means simple communication

Good for small applications

Client/Server:

Separates what presents functionality (client) from what provides functionality (server)

Two-tier architecture makes it easy to support multiple clients, but ties them closely together

Three-tier architecture makes it easy to decouple client from the server or have different clients and servers in one architecture.

Similar is the MVC paradigm

N-tier architecture, lets you decouple even further if necessary, but approaches being component-based.

Component-Based:

The system is a collection of loosely coupled services

SOA:

Like component-based but everything is implemented and consumed as a self-contained program providing one thing.

Data-Centric:

Storing data in a relational database system.

This is so common that it’s easy to think of as a simple technique for use in other architectures rather than an architecture of its own.

Using tables instead of hard‐wired code to control the application.

Some artificial intelligence applications such as rule‐based systems use this approach.

Using stored procedures inside the database to perform calculations and implement business logic.

This can be a lot like putting a middle tier inside the database.

Event-Driven:

Various system components respond to events as they occur.

Rule-Based:

Use a collection of rules to determine work flow through the system

Distributed:

Work is scattered across multiple system, e.g., cloud based systems

Reports

Do we need to track what is happening, who is logged in, etc. beyond just simple logs?

Other Outputs

Do we need to save files, backups, create audio/video files?

Database

Most things need some kind of DB beyond the filesystem

Determine what kind of DB, SQL, NoSQL, XML files, then determine a vendor

Good DB design is a skill unto itself. Get help from a DBA type if at all possible

Consider the need to audit who, what, when, where, and how data was changed.

Consider user access, will it be through the program only, through the DB itself, etc.

Databases need things like redundancy and maintenance, don't overlook these in design

How/When is data purged or backed up

Configuration Data

What needs to be configurable and how will that configuration be read, maintained, modified, etc.

Data Flows and States

It is a good idea to go through the major data flows and states of the system

You may not need to capture everything but it will help make sure you haven't missed something substantial

Training

UML

A big thing unto itself, but in general there are:

Structure Diagrams

Class Diagrams

Composite Structure Diagrams

Component Diagrams

Deployment Diagrams

Object Diagrams

Package Diagrams

Profile Diagrams

Behavior Diagrams

Activity Diagrams

Use Case Diagrams

State Machine Diagrams

Interaction Diagrams

Sequence Diagrams

Communication Diagrams

Interaction Overview Diagrams

Timing Diagrams

WRAP UP:

High‐level design paints an application’s structure in broad strokes.

It identifies the system’s general environment (hardware, operating system, network, and so on) and architecture (such as monolithic, client/server, and service‐oriented).

It identifies the system’s major components such as reporting modules, databases, and top‐level classes.

It should also sketch out how the pieces of the system will interact.

================================================================================

CHAPTER 6: Low-Level Design

Low-level design fills in the gaps before writing code.

High-level focuses on what, low-level focuses on how.

A common way to begin low-level design is to read the requirements and pick out nouns.

Nouns indicate the kinds of object you will likely need to create.

As you're considering classes, think about what sort of information the class should have, its properties.

Making a single instance of a class is a warning sign that it may not be necessary.

Once you know classes in general, you can construct better class hierarchies. This is refinement

Be careful not to over-refine and break OO principles.

Even if a program cares about differences in objects, it doesn't mean it must be sub-classed.

Generalization is the opposite of refinement.

Sometimes it makes sense to make one object that can describe multiple things if those things are not sufficiently different.

As with refinement, don't go overboard.

Once you have the classes, map out the hierarchy and look for warning signs of problems.

Is it very tall and thin?

Are there huge numbers of classes?

Do any classes have only 1 sub-class?

Does the hierarchy make common sense?

Do classes represent differences in properties' values rather than their presence or behavior?

Consider using object composition instead of inheritance.

Give an object properties that are other objects (not just primitives or simple objects like Strings)

Database Design

Relational Databases

First Normal Form (1NF)

1. Each column must have a unique name.

2. The order of the rows and columns doesn’t matter.

3. Each column must have a single data type.

4. No two rows can contain identical values.

5. Each column must contain a single value.

6. Columns cannot contain repeating groups.

Second Normal Form (2NF)

1. It is in 1NF.

2. All non-key fields depend on all key fields.

Third Normal Form (3NF)

1. It is in 2NF.

2. It contains no transitive dependencies. (Non-key field depends on another non-key field)

================================================================================

CHAPTER 7: Development

What are the best ways to actually develop good software?

1. User the right tools.

Programmers easily cost $100,000 a year or more, why argue over a $50 tool if it is the right tool?

Adequate hardware is very important, slow compilation/testing/debugging wastes time and money.

Profilers give you clear insight into how a program is utilizing resources.

Static Analysis tools are a good way to catch typical mistakes and reduce overall bugginess.

Having good testing tools is infinitely better than trying to wing it.

2. Select the right algorithms.

Occasionally, for more difficult problems you'll need a good algorithm.

If at all possible, don't roll your own. Many times there are years of research behind some algorithm.

Algorithms should be:

Effective (They get the job done correctly)

Efficient (They get the job done as quickly as possible, while being effective)

Big O notation

Predictable (Will always do something you expect)

Simple (Can be understood conceptually by a human)

Prepackaged (Get it from library IF AT ALL POSSIBLE)

3. Use Top-Down Design/Stepwise Refinement

Take the requirement and break it into more detailed pieces.

Break these pieces down until there is something you can code.

Examine the pieces and factor out common tasks.

4. Good General Practices

1. Be alert, try not to code when overly tired or distracted

2. Write for people, not the computer.

3. Comment first, saying what the code SHOULD do. Give insight, don't just say what the code is doing.

4. Name things appropriately so the code is understandable with minimal comments (no magic numbers)

5. Keep it small, avoid deep loops (if possible comment the end of a bracket)

6. Stay focused. Classes represent 1 concept, methods do 1 thing.

7. Avoid side effects. Don't do things you wouldn't expect based on a methods name.

E.g., a method called ValidateLogin should not also leave an open connection to the thing.

8. Validate results. Check that you're getting the expected inputs and getting logical outputs.

ASSERTIONS IN PRODUCTION CODE?

9. Practice offensive programming. This is the opposite of defensive programming.

Don't try to do something with every conceivable input, throw errors if you get passed crap.

10. Use exceptions (as opposed to return codes or other unclear values).

Make the system stop and take action.

11. Handle exceptions first.

12. Don't repeat code. Not necessarily a hard and fast rule, but if it can be factored out without trying unrelated logic together, do it.

13. Defer optimization. While optimized code is great, it is for a computer and is often hard to understand.

Optimize after you know the code works as debugging optimized code is hell.

Often times some basic optimization will do the trick (90/10 rule)

================================================================================

CHAPTER 8: Testing

Automated Testing

Load testing

Component Interface Testing

Test interactions between components, often with a time stamp

Accessibility Testing

Is it accessible to visually or hearing impaired people

Compatibility Testing

Does it work in different environments

Destructive Testing

Make the application fail and see what happens

Functional Testing

Nonfunctional Testing

Installation Testing

Performance Testing

Security Testing

Usability Testing

================================================================================

CHAPTER 9: Deployment

================================================================================

CHAPTER 10: Metrics