SOFTWARE CONSTRUCTION
LECTURE 1
Engr. Huma Ayub
huma.ayub@uettaxila.edu.pk
3/18/2016
Software Construction
1
Course outline
•
•
•
•
•
•
•
•
Module 1: Introduction to software construction
Requirement engineering: structural and behavioral modeling using state
machines
1. Introduction to requirements modeling
2. Behavioral modeling
3. Communicating state machines
•
Module 2: Languages, grammars and analyzers
1. Introduction to languages and compilers
2. Lexical analysis (formal languages, regular expressions and accepting
automata)
3. Syntax analysis
•
•
•
Module 3: Concurrency, implementation design and performance issues
1. Concurrency
2 .Implementation design and performance issues
3/18/2016
Software Construction
2
Books (Reference Material )
•
Code Complete - A Practical Handbook of Software Construction (2nd
Edition) [Steve McConnell] (2004)
•
Object-Oriented Software Construction, by Bertrand Meyer, Second Edition,
Published by, Prentice Hall in 1997
•
•
Formal Methods in computing by M. Ferenczi, and Andras Pataricza , Sep
2004
•
Software Engineering by Ian Sommerville, 8th edition, Addison & Wesley.
2006
•
Software engineering a practitioner’s approach by Roger S. Pressman
3/18/2016
Software Construction
3
Grading Criteria
20%
20%
40%
20%
3/18/2016
Mid Term
Quiz and Assignments
Final Exam
Lab Work
Software Construction
4
Software Development Phases
Requirements
What needs to be done
Testing
Check that the code does what
it is supposed to (functionality,
performance, reliability, …)
Analysis
How it should be done
Project Management
Devise a plan, manage
resources, costs, time, …
Coding
Fill in the software
structure with code
Design
Create a software structure
(architecture) around which
code will be built
6
Software Phases Related to this
Course
Coding
Fill in the software
structure with code
Design
Create a software structure
(architecture) around which
code will be built
7
Introduction
Definition of Software Construction:
Detailed creation of working, meaningful software through a
combination of coding, verification, unit testing,
integration testing, and debugging
Software construction closely tied to
• Software design
• Software testing
Design
Construction
Testing
3/18/2016
Software Construction
8
Introduction - 2
•
•
•
•
•
•
More on Construction
Significant detailed design occurs during construction
Low-level (e.g. unit and module integration) testing occurs
during construction
Construction produces high volume of configuration items
• Thus construction linked to configuration management
Construction is tool intensive
Quality (or lack thereof) is very evident in the construction
products
Construction highly related to Computer Science due to
• Use of algorithms
• Detailed coding practices
3/18/2016
Software Construction
9
Introduction - 3
Software Construction Fundamentals
The fundamentals of software construction include:
• Minimizing complexity
• Anticipating change
• Constructing for verification
• Standards in construction
The following slides discuss each of these fundamentals
3/18/2016
Software Construction
10
Introduction - 4
•
•
•
•
•
•
Minimizing Complexity
Humans are severely limited in our ability to hold complex
information in our working memories
As a result, minimizing complexity is one the of strongest
drivers in software construction
Need to reduce complexity throughout the lifecycle
As functionality increases, so does complexity
Accomplished through use of standards
Examples:
• J2EE for complex, distributed Java applications
• UML for modeling all aspects of complex systems
• High-order programming languages such as C++ and
Java
• Source code formatting rules to aid readability
3/18/2016
Software Construction
11
Introduction - 5
Anticipating Change
• Software changes over time
• Anticipation / hope of change affect how software is
constructed
• This can effect
• Use of control structures
• Handling of errors
• Source code organization
• Code documentation
• Coding standards
3/18/2016
Software Construction
12
Introduction - 6
Constructing for Verification
Construct software that allows bugs to be easily found and fixed
Examples:
• Enforce coding standards
• Helps support code reviews
• Unit testing
• Organizing code to support automated testing
• Restricted use of complex or hard-to-understand language
structures
3/18/2016
Software Construction
13
Introduction - 7
Standards in Construction
Standards which directly affect construction issues include:
• Programming languages
• E.g. standards for languages like Java and C++
• Communication methods
• E.g. standards for document formats and contents
• Platforms
• E.g. programmer interface standards for operating
system calls, J2EE
• Tools
• E.g. diagrammatic standards for notations like the Unified
Modeling Language
3/18/2016
Software Construction
14
References
• [IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
2004
• link :
3/18/2016
Software Construction
15
A. Construction Planning
• What is Construction Planning?
Laying out the work plan (i.e. schedule) to design,
implement, debug, and unit test the software
• Construction planning major concerns:
• Coders are typically not planners
• Schedules will be difficult to maintain unless a good
architecture design is in place
• Many organizations to not collect project data on which to
plan future projects
• Many managers consider planning to be a waste of time
and therefore don’t encourage it
• Project plans may be limited to the construction plans
• Many organizations and projects do not use systematic
cost estimating methods such as models
3/18/2016
Software Construction
16
A. Construction Planning - 2
•
•
Improving Software Economics
Consider reducing development costs by planning to:
• Reduce the size and/or complexity
• Improve the development process
• Use more highly skilled people and build better teams
• Use better tools
• Reduce quality thresholds
Some actions include
• Use an object-oriented approach
• Use COTS components
• Use an iterative approach
• Provide training to development team
• Automate tedious tasks with tools
3/18/2016
Software Construction
17
A. Construction Planning - 3
•
•
•
•
Construction Prerequisites
As with building construction, much of the success or failure
of the project already determined before construction begins
Upstream activities such as project planning, requirements,
architecture, and design are crucial to success
Typical high-risk areas
• Project planning
• Requirements
• Architecture
Preparation is a way to reduce these risks
3/18/2016
Software Construction
18
A. Construction Planning - 4
•
•
•
•
Problem Definition Prerequisite
The problem being solved via the application must be well
defined
Common names for the document containing the problem
statement:
• Product Vision
• Vision Statement
• Product Definition
Defines the problem without reference to potential solutions
Helps avoid solving the wrong problem!
3/18/2016
Software Construction
19
A. Construction Planning - 5
Requirements Prerequisite
• Requirements describe in detail what a system is supposed
to do, therefore are invaluable for construction
• Explicit requirements:
• Help ensure the user drives system functionality
• Rather than the programmer
• Reduce the number of construction debates
• Help minimize changes after development begins
• Specifying requirements adequately (sufficiently) is a key to
project success
3/18/2016
Software Construction
20
A. Construction Planning - 6
•
•
•
•
Architecture Prerequisite
Quality of the architecture determines the conceptual
integrity of the system
A proper architecture:
• Gives structure to maintain conceptual integrity
• Provides guidance to programmers
• Partitions work
Architecture-level problems are much more costly to fix than
are coding errors
Good architecture can make construction easy
• Bad architecture makes construction difficult
3/18/2016
Software Construction
21
A. Construction Planning - 7
Regarding Upstream Prerequisites
• Time budgeted for requirements and architecture work
• 10 to 20 percent of manpower
• 20 to 30 percent of schedule
• If requirements are unstable
• Do not ignore, spend time to fix
• The analyst should fix if a formal project
• Can be fixed by the programmer for informal projects
• Use same heuristics for problems with the architecture
3/18/2016
Software Construction
22
A. Construction Planning - 8
•
•
•
•
Choose an Approach
Many software development approaches have been tried
over the years
Some examples (not mutually exclusive):
• Functional
• Object-Oriented
• Iterative
• Waterfall
• Agile
• Data-centric
The construction team must follow some approach
Chosen approach must be appropriate for the task at hand
3/18/2016
Software Construction
23
A. Construction Planning - 9
•
•
•
•
•
Choose a Programming Language
Programming language choices affect
• Productivity
• Code quality
Programmers more productive using a familiar language
High-level languages provided higher quality and better
productivity
Some languages better at expressing programming concepts
than others
The ways in which a programmers express themselves are
affected by the chosen language
3/18/2016
Software Construction
24
A. Construction Planning - 10
Choose Construction Practices
• Questions to answer regarding practices:
• How detailed will the design be?
• What are the coding conventions for names, comments,
layout, etc.?
• How will the architecture be enforced?
• Is the project’s use of technology ahead of or behind the
power curve, and is this appropriate given the
circumstances?
• What is the integration procedure, how often is it done,
and who participates?
• Will developers program individually, in pairs, or some
combination of this?
• Where and when will builds occur?
3/18/2016
Software Construction
25
A. Construction Planning - 11
Choose Tools
Modern programming tools
• Are essential to maintain programmer productivity
• Reduce tedious and redundant tasks
• Must be appropriate for the task at hand
Tools preparation checklist:
• Are all product licenses current?
• Are all products at current, supported revision level?
• Have all programmers received proper training on the tools?
• Does the project have a configuration management tool?
• Does the project have a tool to track change requests?
• Do project team members have sufficient workstations?
• Does the project have sufficient test environments?
• Does the project have sufficient build environments?
3/18/2016
Software Construction
26
A. Construction Planning - 12
Construct the Team
• For small development efforts
• Self managed
• Everyone is a peer
• For mid-size development efforts
Role
• Single team
• For large development efforts Lead
Detailed designer
• Multiple teams
Coder
# / Team*
1
1 to 4
5 to 10
Integrator
1 to 2
Unit tester
Same as coder
System tester
1
“Buildmeister”
1
Configuration manager
1
* Individuals will play multiple roles
Table 1: Team Composition
3/18/2016
Software Construction
27
A. References
• [IE04] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001, June
2004
• [RS04] IBM Rational Software, The Rational Unified
Process v2003.06.13, 2004
• [RT03]
• [SM04] S. McConnell, Code Complete: A Practical
Handbook of Software Construction, Second Edition,
Microsoft Press, 2004.
• [WR01] Walker Royce, Software Project Management, A
Unified Framework, Addison-Wesley, Boston, MA, 2001
3/18/2016
Software Construction
28