Skip to content

Software Engineering

Introduction

  • systematic, disciplined, quantifiable approach to development, operation and maintenance of software

Pros and Cons

Pros:

  • joy in making things
  • making useful things
  • fascinaiton of fashioning complex puzzle-like objects of interlocking moving parts working in cycles built from principles
  • joy of always learning, non-repeating new problems
  • working in tractable medium (easy to work/deal with)

Cons:

  • must be perfect (small error = bug)
  • others set obejctives, resources and information (rely on others not good programs)
  • designing fun till there are little bugs (hours of painstaking labour)
  • debugging and testing drag on, last bugs hard to find
  • obsolete product

Project Management

SDLC Project Models

Basics

  • Softwaare developemnt goes through different stages: requirements, analysis, design, implementation, testing
  • Collectively known as software developemnt lifecycle (SDLC)
  • Several apporach known as software development lifecyclel models/ software process models
  • Describes different ways to go through SDLC - -prescribes 'roadmap' to maange development effort
  • The roadmap describes the aims of the development stages, the outcome of each stage, and the workflow i.e. the relationship between stages.

Sequential Model

  • Aka waterfall model
  • Views software development as linear process: project progress through development stages
  • Drawn to look like waterfall
  • 1 stage process complete --> produce artifacts used in next stage e.g. requirements used in design
  • Strict sequential model, only move in forward direction; no provision for revising requirements
  • Works well for solving well-understood problem (requirements remain stable, efforts estimated accurately, easy to track progress w well-defined outcomes)
  • Real-world projects often tackle problems not well-understood initially, unsuitable for this model
  • Higher risk of overrunning deadlines (non-delivery)

waterfall

Iterative Model

  • Advocates producing software by going through several iterations
  • Each iteration can go through all stages of SDLC (req. gathering to deployment)
  • Each iter. produces new version of product (builds upon previous iteration with feedback)
  • Breadth-first or depth-first apporach
    • Breadth-first: iteration evolves all major components and functionality areas in parallel --> working product at end of each iter (simpler version of complete usabel product)
    • Depth-frist: iteration focus on fleshing out only some components or functionality areas, may not produce working product (each iter a component)
    • Project can be mix of both
  • For fuzzy and evolving requirements
  • Higher wastage

iterative

RCS: Revision History

  • Process of managing multiple versions of a piece of information

Benefits of using automated revision control tool:

  • Track history and evolution of project
  • Easier collaboration (resolve incompatible changes conflicts)
  • Recover from mistakes (revert)
  • Work simultaneously on and manage multiple versions

Repositories

  • Database that stores version history
  • Set up a repo if applying revision control in working/root directory

  • Can have multiple repo in computer

  • RCS tools store the history of the working directory as a series of commits.

  • Each commit in a repo is a recorded point in the history of the project that is uniquely identified by an auto-generated hash
  • You can tag a specific commit with a more easily identifiable name e.g. v1.0.2.
  • To see what changed between two points of the history, you can ask the RCS tool to diff the two commits in concern.
  • To restore the state of the working directory at a point in the past, you can checkout the commit in concern.

testing

Test cases can be determined based on the specification, reviewing similar existing systems, or comparing to the past behavior of the SUT.

For each test case you should do the following:

Feed the input to the SUT Observe the actual output Compare actual output with the expected output

A test case failure is a mismatch between the expected behavior and the actual behavior. A failure indicates a potential defect (or a bug) -- we say 'potential' because the error could be in the test case itself.

Regression Testing

When you modify a system, the modification may result in some unintended and undesirable effects on the system. Such an effect is called a regression.

Regression testing is the re-testing of the software to detect regressions. The typical way to detect regressions is retesting all related components, even if they had been tested before.

Regression testing is more effective when it is done frequently, after each small change. However, doing so can be prohibitively expensive if testing is done manually. Hence, regression testing is more practical when it is automated.

An automated test case can be run programmatically and the result of the test case (pass or fail) is determined programmatically. Compared to manual testing, automated testing reduces the effort required to run tests repeatedly and increases precision of testing (because manual testing is susceptible to human errors).

more info here