Software Architecture, Process and Management · SAPM Problems: I Creativity: Programming is primarily a creative process, managing creativity is di cult I Could a large team write

Software Architecture, Process and Management

Allan Clark

School of InformaticsUniversity of Edinburgh

http://www.inf.ed.ac.uk/teaching/courses/sapmSemester Two 2012-13


Organisational Matters

Me Allan Clark room 5.03 (for about 2-3 weeks) then1.35

email [email protected]

Website www.inf.ed.ac.uk/teaching/courses/sapm

Lectures I Monday/Thursday 17:10-18:00, Hugh RobsonBuilding Lecture Theatre.

I 15 lectures worth of content, I may overrunand/or add some lecture on non-examinablecontent

Coursework I Will be discussed next lecture Thursday 17th JanI Will be individual, critical writing based (no

programming)

Grading I Coursework Assignment — 25%I Final Examination — 75%

www.inf.ed.ac.uk/teaching/courses/sapm

SAPM

No Required TextbookThese (and many others) are relevant:

As we will see there is required reading

SAPM

Could you build a Rabbit Hutch?

SAPM

Could you build the Sheth Tower?


I SAPM is concerned with large scale and long term projects.

I Large scale: Larger than the kind of projects you have donefor coursework. Likely have/require multiple developers. Mayinclude several “deployable components”.

I Long term: development time is measured in years not weeks,support generally even longer

I In this course we are interested in how to make such projectssuccessful

SAPM, Success

A software project is successful if:

I The software is delivered on schedule

I Development costs were within budget

I The software meets the needs of users, in both:I scope andI quality

SAPM

Duke Nukem Forever

Released November 1996 Released Scheduled 1997Released 2011

SAPM, Failure

Failure is almost Ubiquitous

I Success appears common; look around you, you aresurrounded by “working” software

I “ Of the IT projects that are initiated, from 5 to 15percent will be abandoned before or shortly afterdelivery as hopelessly inadequate. Many others willarrive late and over budget or require massivereworking. Few IT projects, in other words, trulysucceed. ” — Robert Charette, Why Software Fails

I “ In 1998, Peat Marwick found that about 35percent of 600 firms surveyed had at least onerunaway software project (Rothfeder 1988).” —Steve McConnell, Rapid Development

I Rates and reports vary widely based on what is measured, butthe message is clear, the majority of large software projectscannot be considered unqualified successes

I Many projects fail in multiple ways

SAPM

Techniques to Avoid Failure

I Since at least the 1960s techniques have been developed (andeven occasionally tested) to avoid failure

I This course will survey some of these techniques

I Many fall under the category of Software Engineering, butothers are considered as well.

I These techniques complement those learned in typicalComputer Science courses, which focus on small-scale projects(which may be a part of a larger-scale project)

I Keep in mind, there is No Silver Bullet or Panacea

SAPM

Problems:I Creativity : Programming is primarily a creative process,

managing creativity is difficultI Could a large team write a novel as well or quicker than a

single authorI Large teams do write creative computer games or films

I Design Space : There is a large degree of flexibility within anygiven programming task

I How do we know we have searched the design space wellenough?

I How do we rank non-functional requirements such as:reliability, scalability, performance, security, maintainance andelegance?

SAPM

TopicsI Planning and Managing Software Projects

I Project management, risk management, planning, projecttools, working in a team (communication).

I Software Development ProcessI Heavyweight vs Lightweight methodologies

I Software Architecture and DesignI Successful (and unsuccessful) architectures for large systems

I The depth of coverage varies widely, we are more concernedwith high-level issues rather than technical details. Moreconcerned with how humans behave rather than how tomanipulate bits

SAPM, Links to other fields

Psychology Programmer motivation, users’ needs

Sociology Programmer group dynamics

Philosophy Software as a model/representation of reality

Business Marketplaces, business models, business practices

Economics I behavioural economics — see lines of code, BillAtkinson

I what-gets-done — see feature matrix syndrome

SAPM

Mark Minasi — The Software ConspiracyMyWord BugWord SmartWords

2.1 2.0 3.0Can boldface text x xRuns on the Atari 520 xAutomatically indents first line of a para-graph

x

Includes game for practicing touch typing x xLets you design your own characters x xGenerates document tables of contents xCan do rotating 3D bullet points in colour x xCan do bulleted lists xSupports Cyrillic symbol set xIncludes Malaysian translater x x

http://www.softwareconspiracy.com/


SAPM

Mark Minasi — The Software ConspiracyMyWord BugWord SmartWords

2.1 2.0 3.0Can boldface text x xRuns on the Atari 520 xAutomatically indents first line of a para-graph

x

Includes game for practicing touch typing x xLets you design your own characters x xGenerates document tables of contents xCan do rotating 3D bullet points in colour x xCan do bulleted lists xSupports Cyrillic symbol set xIncludes Malaysian translater x x



SAPM

Applying SAPM in the real world:

I Every job/position/task is different:I Different companies will:

I use vastly different tools, platforms and development processesI have different cultures expectation and environments

I It is (nearly) impossible to teach general management andproblem-solving skills

I We will do our best

SAPM

Typical Real World Scenario 1I You may find you arrive at a new job at a company with a

well-defined development process, standards and a commonset of tools.

I The tools may of course be obsolete having not been used formany years.

I You will need to be able to work with their system quicklylearning the concepts specific to their setup

I SAPM will give you general experience with typicalapproaches, so that your specific situation can be understoodmore easily.

I For example, you will learn of source code managementsoftware, why it is necessary. Hence whatever specific flavourthe company is using, you should be able to learn it quickly

SAPM

Typical Real World Scenario 2

I A second possibility is to be tasked as part of a small team,possibly even just yourself, charged with a relatively small tasksuch as building a web-site.

I Quite common even if you will ultimately be part of a muchlarger team

I Nearly any development process will work in such cases

I However, following approaches surveyed in SAPM will helpthe system you create to be maintainable over the long-term.

I Additionally it is becoming increasingly common for such asmall-scale project to be given to new employees on atrial basis

SAPM

Typical Real World Scenario 3

I A third possibility is to find a vague development process,loose or no standards and a mishmash of incompatible tools

I It will be appropriate if you can know of the tools andapproaches which are possible, thereby giving a chance ofeffecting positive change

I SAPM will expose you to such tools and approaches

I Bringing about those changes may be challenging, (see stonesoup from the pragramtic programmer).


The Code MonkeyI One day the code monkey got a job at a new firm

I Doing in-house development in COBOL

I On his first day he was told of the coding standards whichincluded: No nested IF statements

I Frustrated but sure of his abilities the code monkey spent allday going through officies and cubicles asking the rationalbehind such a coding standard

I Most claimed they did not know, or made something up aboutreadability

I Finally the code monkey found someone who had been at thecompany long enough to remember:

I The first version of the COBOL compiler contained a bug andcould not handle nested IF statements.

I Of course the bug had been fixed more than a decade beforebut the embarrassing coding convention had remained


The Code MonkeyI One day the code monkey got a job at a new firm

I Doing in-house development in COBOL

I On his first day he was told of the coding standards whichincluded: No nested IF statements

I Frustrated but sure of his abilities the code monkey spent allday going through officies and cubicles asking the rationalbehind such a coding standard

I Most claimed they did not know, or made something up aboutreadability

I Finally the code monkey found someone who had been at thecompany long enough to remember:

I The first version of the COBOL compiler contained a bug andcould not handle nested IF statements.

I Of course the bug had been fixed more than a decade beforebut the embarrassing coding convention had remained

SAPM

What SAPM will not give you

I A recipe for success

I A plug-and-play set of software engineering tools, these arequickly outdated. We will look at general principles.

I Knowledge of all areas of Software Engineering.

I A magic ability to predict schedule, budget and the needs ofusers

SAPM

Relation to other courses

Inf2C: Many SE concepts were introduced in Inf2C. Thosewho have not taken Inf2C may wish to review thematerial on the Inf2C web page as backgroundreading.

SEOC: SEOC is not a prerequisite, but we will try not toduplicate much of the material in SEOC. Inparticular, SAPM is not based on UML, and focuseson abstract issues involving large-scale, long-termsoftware development, rather than specific designproblems or formal notations.


This course will involve a lot of reading


I This course will involve a lot of reading

I But I hope it is pretty enjoyable reading, some of it I mighteven describe as bedtime reading

I Why come to lectures?

I The lectures are the essence of the course, there is a lot ofrequired reading but no required textbook.

I I’m told from experience that few students who do not attenddo well.

I Without attending it is hard to know which of the topics aremost important, why some approaches are better than othersand how it all fits together.


Modularising Programs

I I’m about to say something which might be seen as a tadheretical

I I think all projects should consist of a single source file

I Projects should be modularised for sure, but mapping amodule system onto a (multi-platform) file system isinappropriate

I In the past there existed good reasons for this, but thosereasons have mostly been engineered away and those thatremain could be.

I Of course a project may consist of more than one “deployablecomponents” which may be usefully separated in the filesystem.

I These two statements are commonly believed, but neither istrue:

I “If a program is not split into separate files it is not modular”I “If a program is split into separate files it is modular”




















The contents of a file:

pub l i c c l a s s R o u t i n g I n f o r m a t i o n P r o t o c o l {pub l i c s t a t i c void main ( S t r i n g [ ] a r g s ){

S i m u l a t o r m y s i m u l a t o r= new S i m u l a t o r ( ) ;}

}


Quick Possible RebuttalsI Q. What if my program consists of code written in more

than one language?I A. Those parts are probably separately deployable, and if not

a technical solution allowing more than one language in eachfile, a la JET, etc.

I Q. I have multiple monitors and opening several files allowsme to view different parts simulataneously

I A. I think a technical solution to allow this is pretty simpleand more effective since you wouldn’t have to pre-decide whichparts you wish to view simultaneously


Quick Possible RebuttalsI Q. We have multiple developers, multiple files allow us to

concurrently work on separate parts of the program?I A. That’s what source code control is for and it is a far

better solution for numerous reasons, including one does nothave to decide ahead of time how to split-up the program in toparts which can be worked upon separately.

I Q. Separate compilation allows my program to compile in ajiffy if I only modify a small part of it?

I A. I’ll first need to hop back to the 1980s to answer this.That large a program should have separately deployablecomponents. Even still a technical solution involving diffscould work if you are really still insistent that this is a problem.

SAPM

Summary

I Large-scale and long-term software development is extremelydifficult and unpredictable

I SAPM approaches and tools can help, but are not guaranteedcures

I This course will help expose you to useful approaches andtools

I Many of the most important lessons are difficult to put intowords and summarised in a bullet-point list. They requireexperience with failures and successes

I Embrace failure, it is often good to fail, more importantly wemust recognise when something has failed.

SAPM — Related Reading

I Required ReadingI Software Engineering: An idea whose time has come and gone.

Tom DeMarco, IEEE Software

I Suggested ReadingI A Modular Module System, Xavier LeroyI Why was Pinball removed from Windows Vista, Raymond Chen

Any Questions

Any Questions?

Documents

Software Architecture, Process and Management · SAPM Problems: I Creativity: Programming is primarily a creative process, managing creativity is di cult I Could a large team write