CS 123: INTRODUCTION

TO SOFTWARE
ENGINEERING
Lecture 1
Introduction to Systems, Roles, and Software Engineering
 LEARNING OBJECTIVES
At the end of this lesson, students should be able to:

• Explain what is a system and systems thinking.

• Identify characteristics of software.

• Describe software quality.

• Explain why software engineering and systems analysis & design is important.

• Understand the need for systems analysis & design in an organization.

• Realize what the many roles of systems analysts are.

• Explain the Software Development Life Cycle.

 LEARNING OBJECTIVES
At the end of this lesson, students should be able to:

• Differentiate the different software life cycle models.

• Differentiate Classical and Modern Maintenance.

• Realize the importance of Post-Delivery Maintenance.

• Understand the relative costs in software development projects.

• Understand the difference between software life cycle and life cycle
model.

• Differentiate the types of team organization.

 WHAT IS A SYSTEM?
• An organized collection of highly
INPUT
integrated parts designed to
achieve a desired outcome.1

• It has a wide variety of inputs

which are manipulated through a
process or series of processes in
a manner to produce an output. PROCESS

• A set of interacting independent

components forming an integrated
whole. 2

OUTPUT
 WHAT IS SYSTEMS
THINKING?
• Systems thinking is a way of thinking about…the forces
and interrelationships that shape the behavior of
systems.3

• This discipline helps us to see how to change systems

more effectively, and to act more in tune with the
processes of the natural and economic world.3
 INFORMATION — A KEY
RESOURCE
• Fuels business and can be the critical factor in the
success or failure of a business

• Needs to be managed correctly

• Managing computer-generated information differs from

handling manually produced data
 INFORMATION SYSTEM
• Feedback happens when the
output of a system is fed back as INPUT
input.

• Feedback is used to improve a

FEEDBACK
system

PROCESS

OUTPUT
 WHAT IS A SOFTWARE?
• Computer programs and associated
documentation

• Software products may be developed for a

particular customer or a general market

• Custom - developed for a single customer

according to their specification

• Generic - developed to be sold to a range of

different customers
 PRODUCT
GOODS SERVICES
• E.g., bread, cloth, car, book • E.g., entertainment, consultation,
tourism, care, teaching, delivery
• Characteristics:
• Characteristics:
• Tangible (physical): touch, smell,
see, hear, taste • Intangible (non-physical)
• Consumable • Inseparable: customer should be
present to enjoy the service
• Discretely manufactured
• Non-transferable
Is software a good • Continuum: always improved
or a service?
WHAT FACTORS MAKE YOU
BUY A SOFTWARE?
FACTORS NOT TO BUY FACTORS TO BUY
• Available open source • Nice features: functionality
• Available pirated version • Fast: performance
• Can be developed by ourselves • Reuse: component
• Productivity: reduce cost
• Support
• Update
 SOFTWARE NATURE (1)
• Intangible production cost is very high — hidden cost

• High cost of research

• High cost of development

• Cheap cost of tangible product: disk, packaging

• Construction is Intellectual Value Intensive (high content of

‘brain’)

• Non-consumable: can be used ‘forever’ (as long as the lifetime of

software)

• Short lifetime: 1 - 5 years, maximum of 5 years

 SOFTWARE NATURE (2)
• What is sold is actually information (not the CD, not even the
program itself)

• Solution is complex: requires unusual rigor

• UNIX contains 4 million lines of code

• Windows 2008 contains 50-60 million lines of code

• Malleable: easily shaped (‘soft’) to do almost anything — difficult

to plan, monitor, and control

• Dynamic Environment: adapts to better hardware and

software over time
 WHEN SHOULD YOU BUY
OR BUILD SOFTWARE?
WHEN TO BUY WHEN TO BUILD
• Already exists • Request from the client
• Reuse • For fun
• No testing • Accumulate libraries
• Cheaper (?) • Cheaper (?)
• … • …
 SOFTWARE QUALITY
• Deliver on time

• Within budget

• Functional: does what it is supposed to do

• High performance: efficient in speed, memory, and space

• Usable: user-friendly

• Understandable: well documented

• Flexible: to be utilized as users need

• Maintainable: evolves to meet changing needs

• Reliable (dependable): no crash, works when it is needed, error-free

• Portable (adaptable): compatible with other systems or new environment

 WHAT TYPE OF SOFTWARE ARE YOU
BUILDING?
(ANALOGY)
• Dog house • High-rise building
• lumber, nail, and basic tools • satisfies tenant requirements
• leaking is okay
• needs extensive plan
• if the dog is not happy, get a less
demanding dog • professional team

• Family house

• suits the needs of the family and the

building code

• needs detailed plan

• requires teams of workers

 SOFTWARE ENGINEERING
VS. COMPUTER SCIENCE
COMPUTER SCIENCE SOFTWARE ENGINEERING

is concerned with

• Theory • Practicalities of development

• Fundamentals • Delivering useful software

Algorithms, data structures, SE deals with practical problems

complexity theory, numerical in complex software products
methods

Computer Science theories are currently insufficient to act as

a complete underpinning for software engineering, BUT it is a
foundation for practical aspects of software engineering
SOFTWARE ENGINEERING ≠
PROGRAMMING
PROGRAMMING SOFTWARE ENGINEERING
• Single developer • Teams of developers with multiple
• “Toy” applications roles
• Short lifespan • Complex systems
• Single or few stakeholders • Indefinite lifespan
• One-of-a-kind systems • Numerous stakeholders
• Built from scratch • System families
• Minimal maintenance • Reuse to amortize cost
• Maintenance account for 60% of
overall development costs
 WHAT IS SOFTWARE
ENGINEERING?
• A discipline which is concerned with all aspects of software
production

• Scope

• study of software process, development principles, techniques,

and models

• Goal

• production of quality software that is delivered on time, within

budget, satisfying customers’ requirements, and users’ needs
 NEED FOR SYSTEMS
ANALYSIS AND DESIGN
• Installing a system without proper planning leads to
great user dissatisfaction and frequently causes the
system to fall into disuse

• Lends structure to the analysis and design of

information systems

• A series of processes systematically undertaken to

improve a business through the use of computerized
information systems
 ROLES OF A SYSTEMS
ANALYST
• The analyst must be able to work with people of all
descriptions and be experienced in working with
computers

• Three primary roles:

• Consultant

• Supporting expert

• Agent of change
 QUALITIES OF A SYSTEMS
ANALYST
• Problem solver

• Communicator

• Strong personal and professional ethics

• Self-disciplined and self-motivated

SYSTEMS ANALYST AND HUMAN-
COMPUTER INTERACTION (HCI)
• Increasing demand for analysts capable of incorporating
HCI into systems development process

• Companies realize that the quality of systems and

quality of work life can be improved by taking
a human-centered approach at the outset of
the project
 SYSTEMS DEVELOPMENT
LIFE CYCLE (SDLC)
• SDLC is a phased approach to solving business
problems (or addressing opportunities)

• Developed through the use of a specific cycle of analyst

and user activities

• Each phase has unique user activities

 LIFE CYCLE MODEL
VS.
LIFE CYCLE
• Life cycle model

• The steps (phases) to follow when building software

• A theoretical description of what should be done

• Life cycle

• The actual steps performed on a specific product

SEVEN PHASES OF SDLC
1 Iden'fying
problems,
opportuni'es,
and objec'ves

7 Implemen'ng 2 Determining
and evalua'ng informa'on
the system requirements

6 Tes'ng and
3 Analyzing
maintaining the
system needs
system

5 Developing and 4 Designing the

documen'ng recommended
soCware system
 1 IDENTIFYING PROBLEMS,
OPPORTUNITIES, AND OBJECTIVES
ACTIVITY OUTPUT
• Interviewing user management • Feasibility report containing:
• Summarizing the knowledge • Problem definition
obtained • Objective summaries
• Estimating the scope of the project • Management makes a decision
• Documenting the results whether to proceed with the
proposed project
 2 DETERMINING HUMAN
INFORMATION REQUIREMENTS
ACTIVITY OUTPUT
• Interviewing • Understanding of how users
accomplish their work
• Sampling and investigating hard
data • Knowledge in business functions
• Questionnaires • Begin to be determine how to make
the new system more useful and usable
• Observe the decision maker’s
behavior and environment • Have complete information on:
• Prototyping • People
• Learn the 5Ws and H of the • Goals
current system • Data
• Procedure involved
 3 ANALYZING SYSTEM
NEEDS
ACTIVITY OUTPUT
• Create data flow, activity, or • Recommendation on what should be
sequence diagrams done

• Complete the data dictionary

• Analyze the structured decisions
made
• Prepare and present the system
proposal
 4 DESIGNING THE
RECOMMENDED SYSTEM
ACTIVITY OUTPUT
• Design procedures for data entry • Model of the actual system
• Design the human-computer
interface
• Design the system controls
• Design the database and/ or files
• Design backup procedures
 5 DEVELOPING AND
DOCUMENTING SOFTWARE
ACTIVITY OUTPUT
• SA works with programmers to • Computer programs
develop original software • System documentation
• SA works with users to develop
effective documentation
• Programmers design, code, and
remove syntactical errors from
computer programs
• Document software with help files,
procedure manuals, and web sits
with answers to FAQs
 6 TESTING AND
MAINTAINING THE SYSTEM
ACTIVITY OUTPUT
• Test the information system • Problems, if any
• System maintenance • Updated programs
• Maintenance documentation • Test documentation
 7 IMPLEMENTING AND
EVALUATING THE SYSTEM
ACTIVITY OUTPUT
• Train users • Trained personnel
• Plan smooth conversion from old • Installed system
system to new system
• Review and evaluate the system
SOFTWARE DEVELOPMENT
LIFE CYCLE MODELS
• Code and Fix

• Waterfall

• Rapid Prototyping

• Iterative and Incremental

• Agile and XP

• Open Source

• Synchronize and Stabilize

• Spiral
 CODE AND FIX
• No requirement • No specifications
• No design • Maintenance nightmare

• Easiest way to
develop software
• The most
expensive way
• The most difficult
to maintain
• The worst software
life cycle model
 WATERFALL
• Linear Sequential Model - Generally one phase follows
after completion of another
• No phase is complete until documentation of that
phase has been approved by the Software Quality
Assurance (SQA) group
• Testing is not a separate phase but done throughout
the software development process
• Many versions
 RAPID PROTOTYPING
MODEL
• Build a throwaway version
(prototype)
• Intended to test concepts
and requirements
• Promotes clarity among
stakeholders
• Effort spent pays off for the
clarity
• After agreement from
Rapid Application
customer, usually follows
Development (RAD)
same phases as waterfall emphasizes user
model involvement, prototype,
reuse, and automated tools
 ITERATIVE AND
INCREMENTAL
• Stepwise refinement: the philosophy of continuous
improvement until you reach the final target

• Much better compared to single shot building of waterfall model

• Operations in each phase of development are spread out over

the life cycle

• The basic software development process is iterative

• Each successive version is intended to be closer to its target

than its predecessor
 ITERATIVE AND
INCREMENTAL
• Miller’s Law - at any one time, we only concentrate on
seven chunks (unit of information)

• Incremental Process: use stepwise refinement to

handle large amounts of information

• Concentrate on the currently most important aspects

• Postpone aspects that are currently less critical

• Every aspect is eventually handled, but in order of

current importance
 OPEN SOURCE
• Two informal phases

• First, individual builds an initial version and made available via the
Internet (e.g., sourceforge.net)

• Then, if there is sufficient interest in the project

• initial version is widely downloaded

• users become co-developers

• product is extended

• Keypoint: individuals work voluntarily (unpaid) on an open source

project in their spare time
OPEN SOURCE LIFE CYCLE
MODEL
• First Informal Phase
• Second Informal Phase
• generally, no specification and
no design
• Consists solely of post-delivery
maintenance

• Corrective Maintenance —
reporting and correcting defects

• Perfective Maintenance —adding

additional functionality

• Adaptive Maintenance —porting

How have some open source the program into a new
projects been successful without environment
specifications or designs?
 OPEN SOURCE
• Two groups of users

• Core group • There can not be an open source

• small number of dedicated development of a software product to
maintainers with time and be used by just one commercial
inclination to submit fault reports organization
(“fixes”)
• About half of open source projects on
• takes responsibility for managing
the project Web have not attracted a team to
work on the project
• authorized to install “fixes”
• But when open source model has
• Peripheral group worked, it has sometimes been
• users who submit defect reports
incredibly successful
from time to time
 OPEN SOURCE
• It can be extremely successful for infrastructure projects such as:

• Operating Systems (e.g., Linux, OpenBSD)

• Web browsers (e.g., Firefox, Netscape)

• Compilers (e.g., gcc)

• Web servers (e.g., Apache)

• Database Management Systems (e.g., MySQL)

• Check (sourceforge.net, freshmeat.net, gnu.org)

SYNCHRONIZE & STABILIZE
• Microsoft’s life cycle model based on iterative and incremental

• Requirements Analysis

• Extract list of features of highest priority thru interviews with potential customers

• Draw up specifications

• Divide project into 3 to 4 builds

• Each build is carried out by small teams working in parallel

• At the end of each day — all teams synchronize (integrate components, test, and
debug)

• At the end of the build — stabilize (freeze the build and fixing bugs, no more
change to specification)
SYNCHRONIZE & STABILIZE
• Components always work together

• get early insights into the operation of the product

• requirements can be modified during the course of the build

• no integration problem

• Requires discipline to fix code immediately so the rest of the

team can test and debug

• Needs highly talented managers and developers

 SPIRAL
• Rapid prototyping model plus risk
analysis preceding each phase

• Identify the sub-problem which

has the highest associated risk and
find solution for that problem

• If all risks cannot be mitigated, the

project is immediately terminated
 SPIRAL
POSSIBLE RISKS
• PEOPLE • USERS

• Team is inexperienced • Lack of user acceptance

• RESOURCES
• Team is not familiar with technology
• Schedule is too short
• Unable to hire people with the right
background • Too many users

• Suppliers can’t deliver products depended on

• TECHNOLOGY
• MARKET
• Dependence on technology that
changes • Competitors

• Not fast enough to market

• CORPORATE
• Too fast to market
• Company growth is too fast
• Market trend
 AGILE
• Agile — “the ability to quickly respond to change”

• Controversial and relatively new approach

• Stories (features that client wants)

• Estimate duration and cost of each story

• Select stories for next build

• Each build in divided into tasks

• Test cases for a task are drawn up first

• Pair programming

• Continuous integration of tasks

 AGILE PRINCIPLES AND
PROCESSES
• Manifesto for Agile Software Development

• started by the “Agile Alliance” - a group of 17 software

developers

• recognized the need for an alternative to documentation-

driven, heavyweight software development processes that
does not work for all projects

• does not prescribe a specific life cycle model

• laid out a group of underlying principles

 AGILE PRINCIPLES AND
PROCESSES
• “Manifesto” of values or principles

• Individuals and interactions over processes and tools

• Working software over comprehensive

documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

 AGILE PRINCIPLES AND
PROCESSES
• Deliver working software frequently

• Ideally every 2-3 weeks

• Use of timeboxing to achieve this

• a specific amount of time is set aside for a task

• team members do the best job they can during that time

• timebox do not change — work may be reduced

(“descoped”) to fit a timebox

• Agile processes demand fixed time, not fixed features

 AGILE PRINCIPLES AND
PROCESSES
• Stand-up Meetings

• Short meetings at a regular time each day.

Attendance is required

• Participants stand in a circle

• ensures meetings do not last for more than 15

minutes
 AGILE PRINCIPLES AND
PROCESSES
• Stand-up Meetings

• Agenda — questions answered

• What have I done since yesterday’s meeting?

• What am I working on today?

• What problems are preventing me from achieving this?

• What have we forgotten

• What did I learn that I would like to share with the team?

• Aim: To raise problems, not solve them

• Solution: Found at follow-up meetings, preferably right after the stand-up meeting
 EXTREME PROGRAMMING
(XP)
• Lightweight process model for OO software development

• Code is the center of the process, processes are applied extremely

• Unusual features of XP

• computers are at the center of a large room lined with cubicles

• a client representative is always present

• software professionals can not work overtime for 2 successive weeks

• no specialization

• refactoring (design modification)

 WHY “EXTREME”?
• Extreme execution of selected minimal set of effective agile
practices

• Very short cycles (Planning Game)

• Continuous code reviews (Pair Programming)

• Extensive testing (unit testing, acceptance testing)

• Continuous integration

• Constant design improvement (refactoring)

• Continuous architecture refinement

 FORWARD DRIVING
ACTIVITIES
• Each level provides the minimal materials needed for the next level

• Product activities provide materials for release cycles

• Release planning sessions provide materials for iteration cycles

• Iteration planning sessions provide materials for task cycles

• Task development provides materials for development

episodes

• Development episodes produce the product

 PRODUCT
• Involves chartering, strategy
planning, feature set definition and
USER
planning, investment and resource STORY 1
commitments…

• XP does not provide specific USER

practices STORY 2

• XP assumes Customer does these

things USER
STORY 3
• Primary deliverable: STORIES
USER
STORY 4
 RELEASES
• Whole team gathers

• Review prior progress

USER
• Customer presents stories
STORY 1
• Stories are discussed (analysis) RELEASE 1
USER
• Developer determines technical approach and risk STORY 2
(architecture & design)

• Developer provides initial estimates and options USER

STORY 3
• Customer prioritizes stories
USER
• Customer chooses target releases timebox RELEASE 2 STORY 4

• Stories arranged into probable iterations

USER
• Begin next iteration STORY 5

• Primary deliverable: RELEASE PLAN

 RELEASE PLANNING
• Release: Every 2 - 6 months

• Fixed date, cost, and quality USER

STORY 1
• Determine scope: how many RELEASE 1
stories can be done following USER
development estimates STORY 2

USER
• Most important user stories first STORY 3

• Feedback/ adjustment at every USER

RELEASE 2
iteration STORY 4

USER
• New/ modified stories STORY 5

• Changed estimates
 ITERATION
• Iteration: 1 - 3 weeks long

• For each iteration, the customer chooses the USER

user stories to be implemented STORY 1

• RULE: Choose more valuable first — focus is USER

ITERATION 1
most important parts STORY 2

• Choose which user stories to fix, if there are USER

some that did not pass acceptance tests RELEASE 1 STORY 3

• Choose an amount of user stories that will be USER

completed within an iteration STORY 4
ITERATION 2
• Begin the development of tasks
USER
STORY 5
• Preliminary deliverable: ITERATION PLAN

• Final deliverable: A DEPLOYABLE

SYSTEM
 TASKS
• Programming tasks are identified
from the user stories and failed tests
TASK 1
• Tasks are written down in index USER
cards. Duplicates are removed STORY 1
TASK 2

TASK 3
• Developers sign up for a task and
TASK 4
estimate its duration (1-3 ideal days)
RELEASE ITERATION USER
TASK 5
1 1 STORY 2
• Developer begins an episode to TASK 6
implement
TASK 7
• Developers ensures task is complete USER TASK 8
STORY 3
TASK 9
• If last task, developer ensures story is
complete via acceptance test
 EPISODES
• = Daily development work

• Developer obtains pair partner

• Pair verifies understanding of story for this task (analysis)

• Pair determines detailed implementation approach (detailed design)

• Pair begins test-driven cycle of write test cases, implement to pass, refactor

• At appropriate intervals, pair integrates to code base

• Pair retrospects on progress frequently

• Pair continues until pair changes or task is complete

 CLASSICAL VS MODERN
MAINTENANCE
CLASSICAL MODERN
• Development-then-maintenance • The process that occurs when a
model
software artifact is modified because
• Development or maintenance of a problem or because of a need for
depends on when the activity is improvement or adaptation
performed — TEMPORAL
• ISO/ IEC
• A fault is detected and corrected
one day after software installation • Maintenance occurs whenever
— Classical Maintenance software is modified — regardless
• Same fault is detected and of whether this takes place before
corrected one day before or after installation of the software
installation — Classical product
Development
 MODERN MAINTENANCE
TERMINOLOGY
• Post-delivery Maintenance

• Changes after delivery and installation (IEEE 1990)

• Modern Maintenance (or just maintenance)

• Corrective, perfective, or adaptive maintenance

performed at any time [ISO/ IEC 1995, IEEE/ EIA
1998]
 IMPORTANCE OF POST-
DELIVERY MAINTENANCE
• Bad software is discarded

• Good software is maintained for 10 , 20 years or more

• Software is a model of reality, which is constantly

changing
ESTIMATE ON TIME SPENT
ON SYSTEMS PROJECTS

40% New Systems and

other ac5vi5es
Maintenance of
60% Exis5ng Systems
 RELATIVE COSTS IN THE STAGES
SOFTWARE DEVELOPMENT
• Analysis and Design: 1/3
• Development: 1/6
• Testing: 1/2
Analysis
and Design
Tes4ng 33%
50%

Coding
17%
 RELATIVE NUMBER OF ERRORS MADE IN
THE STAGES OF SOFTWARE
DEVELOPMENT
• Design: 1/2
• Programming and Logic: 1/3
• Syntax: 1/6
Syntax
17%
Design
Programmi
50%
ng and
Logic
33%
 RELATIVE COST OF FIXING
DIFFERENT TYPES OF ERRORS
• Design: 4/5
• Programming, Logic, and Syntax: 1/5
Programmi
ng and
Logic,
Syntax
20%

Design
80%
 RELATIVE COST OF FIXING
SOFTWARE FAULTS
The earlier we detect and correct a fault,
the less it costs
200

30
1 2 3 4 10

e
n
ts

on

on

on
in

nc
sig
en

a6

a6
nn

a
ca

De
m

en
t

gr
a

en
ifi
ire

Pl

te

nt
ec

em
qu

In

ai
Sp

M
Re

pl
Im
 IMPACT OF SYSTEMS ANALYSIS
AND DESIGN TO PROJECT COSTS
• To correct a fault early in the life cycle

• Usually, just a document needs to be changed

• To correct a fault late in the life cycle

• Change the code and the documentation

• Test the change itself

• Perform regression testing

• Reinstall the product (on the client’s computers)

• Between 60% to 70% of all faults in large scale products are requirements,
analysis, and design faults
 TASK SHARING
• If one farm hand can pick a strawberry field in 10 days, 10
farm hands can pick the same strawberry field in 1 day

• One elephant can produce a calf in 22 months, but 22

elephants can not possibly produce that calf in 1 month

• Unlike elephant production, share coding tasks between

members of the team is possible

• Unlike strawberry picking, team members must interact in

a meaningful and effective way
 TEAM ORGANIZATION
• A product must be completed within 2 months, but 1 person-
year programming is still needed

• Solution

• If one programmer can code the product in 1 year, four

programmers can do it in 3 months

• Nonsense!

• Four programmers will probably take nearly a year

• The quality of the product is usually lower

 PROGRAMMING TEAM
ORGANIZATION
• Example: Sheila and Harry code 2 modules: m1 and m2

• What can go wrong?

• Both Sheila and Harry may code m1 and ignore m2

• Sheila codes m1, Harry codes m2. m1 calls m2 and passes 4 parameters;
but m2 requires 5 parameters

• Or, the order of parameters in m1 and m2 may be different

• Or, the order may be the same, but the data types may be slightly different

• This has nothing to do with with technical competency

• Team organization is a managerial issue

 COMMUNICATION
PROBLEMS
• There are three channels of communication between the three programmers
working on a project. Deadline is rapidly approaching but the code is not
nearly complete.

• “Obvious” solution — Add a fourth programmer

• But the other three have to explain in detail

• What has been accomplished

• What is still incomplete

• Brook’s Law

• Adding additional programming personnel to a team when a product is late

has the effect of making the product even later
 TEAM ORGANIZATION
• Democratic

• Classical Chief Programmer

• Beyond Democratic and Chief Programmer

• Synchronize and Stabilize

• Agile Processes

• Open Source
 DEMOCRATIC TEAM
• Programmers can be highly attached to • Solution — egoless programming
their code
• restructure programmers’ values
• They see their modules as • encourage team members to find faults
extension of themselves
• a fault must be considered a normal and accepted
event
• They will not try to find all the
error in his/ her code • modules will “belong" to the team as a whole

• DEMOCRATIC TEAM APPROACH

• everyone is a peer or equal in another way

• competence is measured by the sum of its

parts

• organizational structure is a regular

polygon
 CLASSICAL CHIEF
PROGRAMMER TEAM

• 6 programmer with 5 lines of communication

• Analogy — Chief surgeon directing an operation assisted by:

other surgeons, anaesthesiologist, nurses, other experts

• Two key aspects: Specialization and Hierarchy

 CLASSICAL CHIEF
PROGRAMMER TEAM
• Back-up programmer • Programming
• CPChief programmer
(CP) Secretary
• Chief programmer is only
human
• Successful manager and • Responsible for
highly skilled programmer • Must be as competent as maintaining the program
CP production library
• Does architectural design (project documentation)
• Must know the project as
• Allocates coding among much as the CP • source code listings
team members
• Does black-box test case • test data
• Writes critical (complex) planning and other tasks
sections of the code independent of the design • Converts source code
process
• Handles all interfacing issues to machine readable
• Programmers
form
• Reviews the work of the
team members • Do nothing but program • Compilation, linking,
loading, execution, and
• Personally responsible for • All other aspects are handled running test cases
every line of code by programming secretary (1971)
 BEYOND DEMOCRATIC AND
CLASSICAL CHIEF PROGRAMMER
DEMOCRATIC PROBLEMS CP PROBLEMS

• Beginners are teated as experience • Shortage of highly skilled programmers

programmers
• Shortage of successful managers
• Management difficulties • Qualities needed to be a highly skilled
programmer are unlikely to be found in a
• No one is in charge, no one is successful manager, and vice versa
responsible
• Top programmers and top managers will
• Decisions must wait until it not take a back seat to be a back-up chief
reaches consensus (inefficient) programmer

• Communication problems with team • Programming secretary does nothing but

is larger than 5 members paper work all day — software
professionals hate paper work!!
 BEYOND DEMOCRATIC AND
CLASSICAL CHIEF PROGRAMMER
• Need to organize teams that makes use of strengths of
Democratic and CP — should be able to handle teams
of 20 (or 120) programmers

• Positive attitude for finding faults

• Use CP in conjunction with code walkthroughs or

inspections

• Reduce the managerial role of the chief programmer

• Easier to find a Team Leader than a Chief Programmer

• Team Leader participates in reviews — Team manager is

not allowed to do so

• Team Manager participates in team meetings to appraise

technical skill of the team members
 FOR LARGER PROJECTS

• The non-technical side is similar

• For larger projects, add additional layers

• Decentralize decision making process where appropriate

 SYNCHRONIZE AND
STABILIZE TEAM
• Small parallel teams

• 3 to 8 developers

• 3 to 8 testers (work one-on-one with developers)

• Team is given overall task definition

• Team may design the task as they wish

• Daily synchronization to make sure individual components work together

• Rule: Programmers must strictly follow the time for committing the code into
the server for that day’s synchronization

• Analogy: Let the children do what they like all day…but with a 9 PM bedtime
 AGILE PROCESS TEAM
• Pair programming

• All code is written by two programmers sharing a computer

• Programmers should not test their own code — one draws out test cases, the
other tests the code

• If one programmer leaves, the other is knowledgeable enough to continue working

• An novice programmer can learn from the more experienced programmer

• Centralized computer promotes egoless programming

• No layers between managers and engineers

• “Collective ownership” practice ensure democratic approach — anyone in the team

can change the code
 OPEN SOURCE TEAM
• Generally staffed by unpaid • Individuals volunteer because:
volunteers
• they enjoy working on a
• They communicate asynchronously worthwhile task
(via email)
• they value the learning experience
• They have no team meetings
• they want to gain new skills — for
• There are no managers promotion or getting a new job

• There are no specifications or designs • Many employers view experience

with a large open source project as
• There is little or no other better than additional academic
documentation qualifications
 OPEN SOURCE TEAM
• Open source projects succeed because of:

• the nature of the target product

• the personality of the instigator

• the talents of the members of the group

• The way that a successful open source team is

organized is essentially irrelevant
 CHOOSING APPROPRIATE
TEAM ORGANIZATION
• There is no one solution to the problem of team organization

• The “correct” way depends on

• the product

• the outlook of the leaders of the organization

• previous experience with various team structures

• Little research has been done on software team organization — team

organization has been based on research on group dynamics in general

• Without relevant experimental results, it is hard to determine optimal

team organization for a specific product
 SUMMARY
• Explained what is a system and systems thinking

• Identified characteristics of software

• Described software quality

• Explained why software engineering and systems analysis &

design is important

• Understood the need for systems analysis & design in an

organization

• Realized what the many roles of systems analysts are

 SUMMARY
• Explained the Software Development Life Cycle

• Differentiated the different software life cycle models

• Differentiated Classical and Modern Maintenance

• Realized the importance of Post-Delivery Maintenance

• Understood the relative costs in software development projects

• Understood the difference between software life cycle and life cycle
model

• Differentiated the types of team organization

 REFERENCES
1. Carter McNamara, MBA, PhD, Authenticity Consulting, LLC at:
http://managementhelp.org/systems.index.htm

2. Merriam Webster Dictionary

3. Peter M. Senge, “The Fifth Discipline Fieldbook: Strategies and

Tools for Building a Learning Organization”, The Crown
Publishing Group.

4. CS 123 lectures: Kardi Teknomo, Ph.D.

5. Schach. Object-Oriented and Classical Software Engineering,

8th Ed.