Fundamentals of Software Engineering

Module 5 = Software Implementation/Coding

2011-07-23T13:14:00.000+08:00

What is software construction?

‘Construction’ -->hands-on part of creating something.
a.k.a implementation/coding & debugging & verification & validation (testing) .
focus at coding,debugging,detailed design & some testing.
quality of construction substantially affect the quality of the software.

Why is software construction important?

depending on the size of project.The larger the time spent,the bigger the work affect the success of the project.
Pivotal activity in software development.
great potential for the average programmer’s productivity to improve.
construction’s by product, the source code, is always up to date.
guaranteed to be done!

Coding Principles

Before you write one line of code,be sure you:

Understand the problem you trying to solve.
Understand basic design principles and concepts.
Pick a programming language that meets the needs.
Select a programming environment that provides tools
Create a set of unit test.

As you begin writing code,be sure you:

Constrain your algorithms.
Consider the use of pair programming .
Select the correct data structure.
Understand the software architecture and create interfaces that are consistent with it.
Keep conditional logic simple.
Create nested loops.
Selcet meaningful variable names.
Write code that is self-documenting.
Create a visual layout that aids understanding.

After you've completed your first coding pass,be sure you:

Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you've uncovered.
Refactor the code.

Good programming practices

Be consistent with naming conventions.

Be consistent with formatting.

Use global [identifiers] sparingly.
Don't assume output formats.
Add comment to your code – explain what and why
Provide useful error messages.
Recover (or fail) gracefully.
Push interface up and implementation down.
Know what you don't know – prepare for changes.

Software Inspections

An "old school" approach
review,analyze and check static system
Focus at source code
a.k.a peer reviews or program/code inspection
check conformance with a specification but not conformance with the customers real requirements.
cannot check non-functional characteristics.

Reuse-based software engineering

Application system reuse

may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families

Component reuse

components of an application from sub-systems to single objects

Object and funcion reuse

Software components that implement a single well-defined function may be reused.

Requirement for Reuse

possible to find appropriate reusable components
the component must be confident that the components will be reliable
must be documented

Benefits of reuse

• Increased dependability

–Software/components/function has been tried and tested in working systems, so should be more dependable than new software.

• Reduced process risk

–Less uncertainty in development costs especially if a large software components are reused.

• Effective use of specialists

–Reuse components instead of people. The specialist can create reusable components

• Standards compliance

–Standards such as UI standard (e.g., drop-down menu) can be implemented as reusable components to improve dependability as users are less likely to make mistake

• Accelerated development

–Avoid original development, speed-up production and hence able to market product early

Reuse Problems

Increased costs
Lack of CASE tool support
Not-invented-here syndrome
Maintaining a component library can be expensive
Finding ang adapting reusable components

Module 4 - Software Design

2011-07-22T23:06:00.012+08:00

What is design?

-Based on dictionary, design is a plan or drawing produced to show the look and function or workings. On software engineering perspective, design creates a representation or model of the software. Design also provide software architecture, data structure, interface and component.

McGlaughin state that design :

1. Must implement all of the explicit requirements contained in the analysis model.

2. Must be readable.

3. Must be understandable.

4. Should provide complete picture of the software.

Design principle

-Davis state that design:

1. Should not suffer from 'tunnel vision'.

2. Should be traceable.

3. Should not reveint the wheel.

4. Should exhibit uniformity and integration.

5. Should be structured to accomodate change.

6. Design is not coding, coding is not design.

7. Design should be reviewed to minimiza conceptual errors.

Tunnel vision

Design concept

- Fundamental design concepts that span both traditional and object-oriented software include:

1. Abstraction

2. Architecture

3. Patterns

4. Modularity

5. Aspects

6. Design class

Abstraction

- Abstraction define by something that exist only as an idea.

- Designers should work to derive both procedural and data abstraction that serve the problem.

- There is 2 type of abstraction:

1. Procedural abstraction - Sequence of instruction that have specific and limited function.

2. Data abstraction - A named collection of data that describes a data object.

Architecture

- Are all about describing fundamental organization of the system, identifying its various components and their relationships to each other, the enviroment in order to meet the system's quality goals.

Modularity

- Modularity is when software is divided into components.

Modularize a design is:

1. To ease the planning for implementation.

2. To define and deliver software increments.

3. To easily accomodate changes.

4. To efficiently test and debug program.

5. To conduct long term maintenance without serious side effects.

Without module With module

Module 3 - Requirements Engineering

2011-07-20T23:14:00.000+08:00

What are 'requirements'?
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed a system or system component to satisfy a contract,
     standard, specification or other formally imposed document.
(3) A documented representation of a condition or capability as in (1) and (2).

Types of requirements
1. Functional requirements
   - A requirement that specific a function that a system or system component must be able to perform.

2. Non-functional Requirements
   - A requirement that specifies quality characteristic/attributes of the software and constraints of the software
     to be developed and/or process to develop the software.

What is Requirements Engineering (RE)?
Sommerville & Sawyer (1997) - ...a relatively new term which has been invented to cover all of the activities
                                                  involved in discovering, documenting, and maintaining a set of requirements
                                                  for a computer-based system. The use of the term 'engineering' implies that
                                                  systematic and repeatable techniques should be used to ensure that systems
                                                  are complete, consistent, relevant, etc.

Why is RE important?
1. RE process can influence the development cost, time, effort, and quality of the product.
2. RE process is an essential contributor to the overall quality of the software product.
3. "Incomplete requirement" and "changing requirement" are major causes of project failures.
4. Good RE practice contribute more than 42% toward overall success of a project, while improper RE
    practices account for more than 43% of the reasons why projects are late or over budget.

RE Process
Main tasks:

- Requirements Elicitation

- Requirements Analysis and Negotiation

- Requirements Specification

- Requirements Verification and Validation

- Requirements Management

Requirements Elicitation
1. Understanding application domain
2. Understanding problem to be solved
3. Understanding business processes in an organization
4. Understanding the need and constraints of the stakeholders

Why is it difficult to understand what the customer wants?
1. Problems of scope
    - system/software boundary is ill-defined
    - Customer/users specify unnecessary technical detail that may confuse overall system/software objective
2. Problems of volatility
    - requirement change over time
3. Problem of understanding
    - customer/users not sure what they want
    - poor understanding of the capabilities and limitation of their own computing environment
    - don't have full understanding of the domain problems
    - have trouble communicating need
    - omit information that is believed to be "obvious"
    - specify ambiguous requirement
    - specify conflicting requirements

Requirements analysis & negotiation
-Build analysis model (or requirements model)
-Prioritizing requirements
-Conflict and conflict resolution
-Negotiation requirements
-Assessing requirements risk

Techniques of Requirements Prioritization
- Prioritization scale
- QFD
- Semi-quantitative analytical approach

Negotiating Guidelines
1. Recognize that it's not a competition
2. Map out a strategy
3. Listen actively
4. Focus on the other party's interests
5. Don't let it get personal
6. Be creative - think out of the box!
7. Be ready to commit and move on

Requirements Specification
Attributes of a well-written Software Requirements Specification (SRS):

- Correct

- Unambiguous

- Complete

- Consistent

- Ranked for importance or stability

- Verifiable

- Testable

- Traceable

Requirements Verification & Validation

1. Reviews the requirements specification

- Desk-check

- Walkthough

- Inspection

- Checklist

2. Prototyping

3. Acceptance Tests

Requirements Management

1. Managing changes to requirements

2. Managing configuration of requirements and requirements document

3. Maintaining requirements traceability

4. Tracking requirements status

Module 2 - Software Process

2011-07-20T21:31:00.000+08:00

A software process:

A collection of work activities, actions, tasks, which are performed when software is to be created.

A process model or framework:

is where these activities, actions, and tasks reside, and that defines their relationship with the process and with one another.

- The technical work hierachy - activities encompassing actions, populated by tasks.
- Each action is defined by a set of task that defines:
       1) the actual work to be completed
       2) the work products to be produced
       3) the quality assurance filters to be applied
       4) the milestones that will be used to indicate the project and product progress

Process Activities:
Framework activities
- generic activities that are applicable to all software projects, regardless of their size or complexity.
- Include communication, planning, modeling, construction and deployment.

Umbrella activities
- complementary activities applied throughout a software project and help manage and control progress,
quality, change, and risk/
- Include project tracking and control, risk management, software quality assurance (SQA),
technical reviews, configuration management (CM).

Process Flow
1) Linear - execute the framework activities in sequence.
2) Iterative - repeats one or more of the activities before proceeding to the next.
3) Evolutionary - execute the activities in a 'circular' manner.
4) Parallel - execute one or more activities simultaneously with other activities.

Process Assessment and Improvement
Approaches:
1. Standard CMMI Assessment method for process improvement (SCAMPI)
2. CMM-Based Appraisal for internal process improvement (CBAIPI)
3. SPICE (ISO/ICE 15504)
4. ISO 9001:2000

Prescriptive Process Models
1. Waterfall Model - represents elements of a linear process flow.
2. Incremental Model - combines elements of linear and parallel process flows.
3. Evolutionary Model - follow the evolutionary process flow that combines elements of linear and iterative
    process flows.
4. Concurrent Model - combines elements of iterative and parallel process flows.

The Waterfall Model

The V-Model

The Incremental Model

The Evolutionary Model: Prototyping

The Evolutionary Model: Spiral

The Concurrent Process Model

Specialised Process Models
- Component based software development (CBSD)
- Formal methods
- Aspect-oriented software development (AOSD)
- Unified Process
- Agile process
- Personal process model
- Team process model

Selecting a Process Model
Factor:
1. The characteristic of the problems to be solved
2. The characteristic of the product
3. The project environment in which the software team works

Task 4:

2011-06-20T22:28:00.006+08:00

Myth is all about legend or something we recognize as a part of tales that continuously go along the time, somehow the fact could be true or false but it is still become famous among the others who believe with it. In other word it’s may be good otherwise it’s become worth. In term of software management, the myth will goes around the meaning of quality management, cost of belonging, time that under going to be pursuing , thus who suppose to be able to use in term of the last user and a lot of matter will come out by currently idea that been exposed in our mind. Talk about discussion even though the discovery should have a reason and the idea naturally goes at random without curious about the order. Actually, their had many kind of myth but according to our task 4 we suppose to discuss about those three type of myth :-

1) Software management myths

2) Customer myths

3) Practitioner myths

1) Software management myths

Myth 1: Risk of losing data with an Electronic Quality Management System

One of the more persistent myths associated with QMS systems involves the perception that the electronic storage of data is somehow riskier than retaining paper versions of the data. In fact, electronic documents are far safer than any other methods of documentation. Ask yourself a question: Do you back up the files in your cabinet every day? Probably not, but with an electronic QMS, you can create a backup of all your data every night, therefore ensuring that your data is always safe and secure. Do you have a copy of your paper system off site? With an electronic QMS, this is normal - or at least it should be.

When you are looking for ways to save administrative costs, increase employee productivity, improve business performance, and speed up the customer response process, an electronic QMS is a must-have. Deploying a QMS through on-demand / SaaS solution is a hassle-free and cost-effective route for small and medium sized enterprises.

Myth 2: Allocating extra resources to a late project allows it to catch up with the project schedule.

A software project is not a mechanical process such as, say; digging an artificial lake. In case of creating an artificial lake, adding more people to the job can help dig a larger area in the same time. However, in a software project, adding, more people actually increases the time required to finish the project. This happens because a new person joining the project requires time to understand the requirements of the client, software design, and standards. Moreover, the existing people in the project need to devote time and effort to train the new people on the software project. Therefore, allocating additional resources to a risky situation increases the risk to the software project.

Myth 3: As software by itself is flexible, changes in the requirements can be made at any point in the software project life cycle.

Requests for changes are common with all projects. However, the timing of the change for requests is critical. This is because an untimely change adversely, impacts the cost of the software project. For example, a change request during the requirements gathering stage has a relatively low impact on costs. On the other hand, a change request during, the software construction stage can be extremely expensive to incorporate. The software project manager must decide with the customer upon a set of objectives that must be achieved at the end of the project. In addition, the project manager and the customer must decide on a specific phase, beyond which only critical change requests are accepted.

Myth 4: Deploying an Electronic Quality System can cost companies huge sums of money

The demand for quality management software has increased the competition amongst vendors. Companies can select an electronic QMS at an affordable price. Many vendors now offer less-expensive, cost effective quality management software through services such as on demand / SaaS, where the software is hosted on the vendor's server. Additionally, this reduces the cost of ownership by over 60% and makes the implementation possible in days, rather than weeks, all for a small monthly fee.

Myth 5: Poor to no return on investment on Quality Management Software

When considering the use of a QMS, senior management will usually question the QMS's potential return on investment. Various studies show that using software for quality management can save administrative time, reduce printing costs, improve production cycles, speed up change control processes, and improve speed of response - all of which adds up to a considerable return on investment. One of the biggest costs relates to risk; a good QMS will substantially reduce the risk of incorrect documentation like specifications or inspections being used and can thus provide a difficult to quantify, yet significant savings. Depending on the scope of implementation, a QMS can offer return on investment in as little as 12 months.

Myth 6: Only Technical Personnel can use Quality Management Software

It is a common misconception that anything relating to software is in the realm of an organization's technical team. It gives rise to this myth that only IT departments / technical personnel of companies can handle and use electronic quality systems. The fact is, there are quality management programs which are designed for everyday users who are familiar with internet usage - programs designed to be user-friendly and intuitive. In essence, anyone who can surf the internet can easily use a well-designed electronic QMS system. Further, quality management software is far easier to use than a paper-based system, as the QMS software will typically include help manuals and technical support. Moreover, deploying software through an on demand service doesn't even require an IT department, as the vendor has a support team that installs and implements the software.

Myth 7: Electronic Quality Systems are only for big companies

This prevalent myth asserts that an electronic QMS is designed and meant only for large organizations with multiple sites. The fact is, that in such a competitive environment, it is mandatory for every organization to track and control documents, manage non-conformances, and adhere to regulatory requirements - whatever the company size, amount of locations, or number of employees. All companies must demonstrate the highest standards and quality to auditors if they are to be certified to a standard that meets industry regulations, as well as customer demands. Achieving these goals can be easy with an electronic QMS that ensures continuous improvement, critical information security, issue visibility, quick problem resolution, and fast regulatory approval .In order to effectively and efficiently market new products.

2) Customer myths

A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing /sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths led to false expectations and ultimately, dissatisfaction with the developers.

Myth 1: A general statement of objectives is sufficient to begin writing programs we can fill in details later.
Reality : Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.

Myth 2: Project requirements continually change, but change can be easily accommodated because software is flexible.
Reality : It's true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly - resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.

3) Practitioner myths

Myth 1: Once we write the program and get it to work, our job is done.

Reality: Someone once said that “the sooner you begin ‘writing code’,the longer it’ll take youto get done.” Industry data ([LIE80] [JON91] [PUT97]) indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.

Myth 2: The only delecerable work prduct for a successful project is the working program.

Reality: Aworking program is only one part of a software configuration the includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.

Reference List:-

http://b-eye-network.com

http://www.wikipedia.org 

http://ezinearticles.com 

http://free-books-online.org

Task 3:

2011-06-16T00:10:00.002+08:00

Based from our reserch at the http://www.jobstreet.com.my/ we found that to take a job as Software engineer or System Analyst a candidate must have at least 2 years working experience so that they are worthy for the company to take them as a worker.Besides that a skill worker also needed by the company so that their effort are not useless for taking a person as they worker.The salary also quite big for people to have.

Task 1 : About Us.

2011-06-08T23:52:00.002+08:00

Subject : Fundamentals of Software Engineering
Subject Code : CSEB 233
Lecture : Mdm Badariah Binti Solemon

We has being assigned to form a group which has 4 team member's.

To know further info about our team member please feel free to visit the page titled About Us.Thank you.

Module 1

2011-06-07T21:43:00.008+08:00

MODULE 1

(Introduction to Software Engineering)

What is 'software'?

-Instruction that when executed, provide desired features, function, and performance.

-Data structures that enable the programs to adequately manipulate information.

-Documentation that describes the operation and use of the programs.

Example of software

Software Application Domain

System software
Application software
Engineering/scientific software
Embedded software
Product-line software
Web applications (WebApps)
AI software

System Software

Basically, system software written to service other programs and also provide a platform for running application software. The most basic types of system software is operating system which allows the parts of a computer to work together by performing tasks. The general example of system software is Microsoft Windows and Mac OS.

Application Software

Application software was design to help user to perform singular or multiple related specific task. Application software is contrasted with system software, which manage and integrate a computer's capabilities, but typically do not directly apply them in the performance of tasks that benefit the user. The system software serves the application, which in turn serves the user. For instance, enterprise software, accounting software and media player.

Engineering/Scientific Software

The software function as tools to for statistical data analysis, useful for work in of fields of engineering and scientific analysis. Example as LISREL 8.8, HLM 7, and many more.

Product-line software

Generally, manufacturers have long employed analogous engineering techniques to create a product line of similar products using a common factory that assembles and configures parts designed to be reused across the product line. Also product line software is a collection of similar software systems from a shared set of software assets using a common

WebApps

Web application is an application accessed all over a network that being hosted in browser-controlled environment. For instance, web-mail, online auction and etc.

AI Software

Is a study, design of intelligence agents and it is highly and specialized and also deeply into sub field that often fail to communicate with each other. As example, expert system, diagnostic medical expert system, etc.

Realities of Software

Software must be adapted, enhanced, extended, re-architected to meet the need of new computing enviroment, to implement new business requirement, to make it interoperable, and last but not least to make it viable within a network environment.

Post 1 : Why This Blog is Born

2011-05-29T21:29:00.005+08:00

Welcome..

This is a testing post coz this blog is for our subject CSEB233 task that have been directed to do by our lecturer that is Mam Badariah Binti Solemon. So that we are very sorry if there any problem for the people who are reading this blog..